Feature: Read dependencies from a file

[joshooaj]

I typically declare dependencies in a file in my repos, most often in a PSD1 file used by PSDepend. Since I want to support easy bootstrapping of a local development environment or devcontainer, I want my list of dependencies to remain independent from my GitHub workflows. And in the spirit of DRY, I don’t want to have dependencies defined in two places where they will inevitably drift over time.

To avoid rewriting my dependencies in my workflows in PSPushover, I added a step before psmodulecache to pull the modules and versions out of my PSD1 and write them to the step’s output so that I could reference them as a variable in the psmodulecache step.

Are you open to a PR for an option to reference a file in the repo to get the list of dependencies? Or maybe too few would use it to justify the effort? Especially since people may have a wide variety of formats they’d want to use (psdepend vs modulefast vs ??). In that case maybe an example of a workaround like I used would be good enough?

      - name: Load PSDepend Requirements
        id: psdepend
        shell: pwsh
        run: |
          $reqs = Import-PowerShellDataFile ./requirements.psd1
          $moduleNames = $reqs.Keys | Where-Object { $_ -ne 'PSDependOptions' -and $null -eq $reqs[$_].DependencyType }
          $dependencyList = ($moduleNames | Sort-Object | ForEach-Object { '{0}:{1}' -f $_, $reqs[$_].Version  }) -join ', '
          "psdependencies=$dependencyList" >> $env:GITHUB_OUTPUT

      - name: Install and cache PowerShell modules
        uses: potatoqualitee/[email protected]
        with:
          modules-to-cache: ${{ steps.psdepend.outputs.psdependencies }}

[LaurentDardenne]

Hi,

Are you open to a PR for an option to reference a file in the repo to get the list of dependencies?_

I don't own this repository, but it is OPEN source. So I agree :-)

The fact remains that the PSModuleCache code is starting to become unmaintainable, but we can add other patches :-) Finally, we must not forget a possible future migration to 'PSResourceGet'.

Especially since people may have a wide variety of formats they’d want to use (psdepend vs modulefast vs ??).

Note that 'PSDepend', although functional, no longer seems to be maintained and Modulefast seems to me to be dedicated to Powershell v7 (but I could be wrong). But for me it's not so much the addition of features that poses a problem but the scenarios to cover and build with Pester.

For example : How to use a MyGet repository with PSDepend? How to use a private repository with PSDepend? ~~How to find out the targeted repositories?~~ How do I know the targeted repository names?

~~In that case maybe an example of a workaround like I used would be good enough?~~

~~The -IncludeDependencies parameter of Find-Module does not handle external dependencies even though a dedicated key exists into the manifest file...~~ ~~That's why I didn't take these scenarios into account.~~

~~We can add a parameter with a particular formalism which would carry several pieces of informations (PSDepend\PathFile ?), but It's like eating peanuts, you always know where it starts, never when it stops ;-)~~

[joshooaj]

Thanks @LaurentDardenne! I agree that supporting dependency/requirements file formats for specific modules like PSDepend is more trouble than it's worth, for all the reasons you outline. If there were one definitive

If this were to support reading modules from a file, it might be best to keep it as simple as possible and have one entry per line. If I wanted to continue to use PSDepend or any other tool to handle dependencies during local development, I could run a build step to generate a file for psmodulecache. But at that point, I guess it wouldn't be much different than my workaround to write to GITHUB_OUTPUT, so maybe it doesn't make sense to bother with support for file input after all :)

[LaurentDardenne]

But at that point, I guess it wouldn't be much different than my workaround to write to GITHUB_OUTPUT

For the moment it is preferable.

so maybe it doesn't make sense to bother with support for file input after all :)

I needs to study what this implies, but first I need to finish implementing private repository support...

[LaurentDardenne]

According to the number of PSGallery downloads, PSDepend is the most used as a dependency manager.

If we integrate this need, analysis of an external PSDepend file, in order to complete the 'modules-to-cache' parameter, we couple the two modules. It is possible but in this case it is necessary to reference and process all possible syntaxes of PsDepend. There is also credential management to integrate (https://github.com/RamblingCookieMonster/PSDepend/tree/master?tab=readme-ov-file#repository-credentials).

I found this action (https://github.com/IT-Service/Invoke-PSDepend) but it only encapsulates a call to Invoke-PsDepend, it does not use the cache action. It seems to me that the most appropriate solution for this need is to add this functionality in a dedicated action (PsDependCache) which would use the Requirements.psd1 file of the project and not a parameter to complete.

But your initial request is not to create other projects :-)

[SamErde]

The fact remains that the PSModuleCache code is starting to become unmaintainable

As an observer who recently discovered PSModuleCache and was thinking about using it, I'm very curious what you mean by this statement--both from a "should I use it" perspective and a "what can I learn from the why" perspective. Thanks!

[LaurentDardenne]

@SamErde

"should I use it"

Yes, no need to know the module code.

"what can I learn from the why"

Originally the code was simple and sufficient. I added checks so that a new user knows what is wrong with the settings. In doing so, I coded procedurally by chaining and coupling the treatments. Adding functionality like here becomes difficult. I was thinking about a refactoring using Powershell classes and a framework of this kind.

By defining many scenarios, I was able to avoid some potential problems, although they are rarely encountered. The Pester tests also need to be rewritten/clarified.

I used the word 'unmaintainable', because it was at the end of the project that I understood how to do it better ;-)

[SamErde]

Thanks for the explanation. That makes a lot of sense (especially the last part!) 😄