Guidance on External Module Dependencies

[brotherdust]

Hello! This is such a great document! Thanks to all the community for putting it together.

I am authoring a module that I'd like to be re-usable by others. This module depends on other third-party modules. What's the best or "least wrong" way to define these dependencies in such a way as that, when a user downloads the module, the dependencies will be downloaded, too?

Thanks much!

[ChrisLGardner]

Use the RequiredModules section of the psd1 file and then PowerShellGet will handle the rest for you.

[brotherdust]

Thank you for such a fast reply!
One more question: is there a way to "test" that the modules specified in RequireModules work? Like a sort of fake or mock install?
Thanks again!

[Jaykul]

Not sure what you mean, exactly. Testing that PowerShell or PowerShellGet work is kind-of outside the scope of your module, right? I mean, there are tests in their repositories, and you can validate how the installation works with existing modules such as ModuleBuilder which depends on Configuration, or PowerLine which depends on Configuration and PANSIES -- or even the "Az" module which is a "meta module" that installs about 60 dependencies...

For what it's worth ...

Faking out the module during installation with PowerShellGet is complicated, because they do extra (file system) checks when installing (they keep metadata files with the modules that they install), so the existence of a module on your system will not convince them to skip installing the version that comes from the same gallery you're installing from.

However, you can easily create a new PowerShellGet Source by registering a folder on your system as your source, and sticking (real or partial or metadata-only) modules in there to trick PowerShellGet into not installing the real modules. Additionally, there's an ExternalModuleDependencies property you can put in your module's PrivateData\PSData in order to tell PowerShellGet that some dependencies should be managed outside of PowerShellGet...