Nuget package as module about invoke-build

[nightroman]

Done. Sorry that it took so long to get me convinced.

[BartDubois]

Hi,

Thank you for the response and I'm sorry for delay.

The reason I ask for adding the module definition lays exactly in the difference between the purpose of usage. It is more convenient to use nuget.org in development environment (like visual studio). All the dependence of the solution's projects can be expressed in package.conifg for both, code, and development used for improving build process. The second one type of relation is the place where Invoke-Build fit very well.

Unfortunately treating it as the script provide less readable and structure of the build process. From the other hand using it as pure module, from powershell gallery, require additional effort to configure environment. This include both the developer machine and build server.

So what we get use the nuget.org as the structure in development environment:

• consistent way of managing all project dependencies, by package.config just like npm in node
• simple way of restoring the development environment. We can use automatic restore packages during build, using UI of the IDE as well as nuget.exe restore in solution folder. Most of automated build tools like TeamCity, Jenkis can also trigger restoring before starting other tasks.
• powershell can be used as the fill the gap, of the msbuild, in the area of describing the full process or CI

I looked at the projects that use the PowerShell and Invoke-Build for this approach. All of share the same problem with lack of standard way of dealing with PowerShell extensions. One are scripts and other are modules. So the code is mix of fallowing lines:

• Import-Module (Find-Item '../packages/pester.*/pester.psm1')
• & (Find-Item '../packages/Invoke-Build.*/Invoke-Build.ps1') -....

Both are hacks rather the real solution. What I found usefull si the #Requires statement. To be more detailed -Module option. This allow to write scripts in this form: #Requires -Modules pester,invoke-build,...

To make it work with packages.config and automatic nuget restoring, based on OneBuild, very simple bootstrap script that do the fallowing:

1. restore nuget packages
2. extend Install-Module so first it search packages folder for modules and only if not found use the standard Install-Module rutine.
3. execute script that has the #Requires statement.

Of course and enrich manual the nuget packages that do not have the module definition with the psd1/psm1 files. As the result I found that I got fallowing results:

• the final scripts can be started using bootstrap script, and from powershell command line if the modules ware installed globally.
• using bootstrap script started on CI server create consistent workspace for the time of running CI process.

I think that there is the place for both packages, gallery and nuget.org, because they serves the same module to different audiences. The difference is only in the package file organization. It hard to tell that it will be unified one day, but this is yest another story :).

I like the way Invoke-Build allow to organize process. I do not fully understand the script approach in nuget.org package, but agree that if peoples will see the psd1 they could first threat is as the module first.

I hope you will find my explanation useful to think about it.

Thanks

[nightroman]

Hi Bart,

Thank you for the suggestion. Could you please provide some more reasoning?

Here is what we have. There are two packages:

1. A module at PowerShell Gallery, the modern place specifically designed for PowerShell modules.
2. Scripts at nuget.org, the place for all kind of stuff, also used for PowerShell because there was not much choice.

Thus, we have a module package that you are asking for. If you need a module
then use (1). If some people prefer scripts then they use (2).

So there is a choice and I think this is a good thing. Note that Invoke-Build
is a script in the first place, not a module, and I would like to emphasize
this important fact and encourage using it as a script.

[nightroman]

Please feel free to reopen with more input.

[nightroman]

@BartDubois, thank you for the detailed answer and useful explanation. I promise to think of this. It is so simple to add two files to the package, indeed. I just feel some "smell" and have doubts.

[BartDubois]

@nightroman thanks.

[nightroman]

Hi @BartDubois,
I am reopening this. The next version of the "script" package will include module files, just as you suggested. I do not see any real drawbacks, after all.

[BartDubois]

No problem. Thank you.