Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add recursive search to GetModuleFilePaths so that modules can be maintained in folders. #1072

Conversation

davidobrien1985
Copy link
Contributor

As mentioned in #906 I am forking the recursive search of module files out to its own PR.

@mathewc and @tohling fyi

@mathewc
Copy link
Member

mathewc commented Jan 3, 2017

Merged in 227a600 thanks David :)

@mathewc mathewc closed this Jan 3, 2017
@KirkMunro
Copy link

@davidobrien1985 and @mathewc, is there a reason why Azure Functions doesn't use a shared Modules folder that is accessible to all Azure Functions in a Function App, and that is automatically registered in $env:PSModulePath in any sessions that are created to invoke Azure Functions that contain PowerShell scripts? The current approach (searching folders for files, and even doing that search recursively) is definitely reinventing the wheel, and in a broken way that takes us many steps back in what modules are for, how they are designed, and how they are used. Use of $env:PSModulePath is essential to this really working properly...otherwise you're going to force users to modify modules just to get them working in Azure Functions. If we get this set up properly to support $env:PSModulePath, then later someone could theoretically add a Deploy to Azure Function App button much like the Deploy to Azure Automation button that exists in the PowerShell Gallery today, making deployment of modules to Azure Function Apps automated and error free rather than manual, error prone, and requiring modification to work properly.

As an example, I just copied up two published, signed modules into a modules folder I created in the appropriate location in Azure Storage (under a specific Azure Function where I want that module available), one of which nests the other one via the NestedModules feature in the manifest, and the modules won't load because the nested module is loaded by name (which is the best practice and right way to do it) instead of by path (the wrong way to nest modules). My LodPx module won't load as is because SnippetPx isn't found since it's not part of $env:PSModulePath on the system where this is run. If I wasn't the owner/author of these modules, I'd have to download them local, remove the signatures in files I need to modify, and then change the files around to make them work.

All of this said, I don't have the history behind why things are currently designed and working the way they are, so I wanted to bring this up here before pursuing it further. If this is just an oversight, then I'll open a new Issues thread to discuss it and propose a solution, and I'll probably look at submitting a pull request as well (although I'm not sure how that works for this as far as testing goes with it being a cloud service, but I'll have to figure that out). If this is a design decision that has to be this way, knowing why will help me figure out what can be done to change that decision. Either way, your comments are greatly appreciated! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants