Better Support for NuGet / Pkg Mgr Console about psbuild HOT 7 OPEN

Makes sense!

Regarding the first list item: AFAIK, the only way to "inherit" commands from another package (without relying on the file system, such as the package installation directory) is by exposing them in the NuGet PowerShell profile.

Having a dependency to PSBuild would not make its commands available to the scripts contained within the depending package (unless perhaps with the approach taken in the first list item below?).

Also:

• The PSBuild NuGet package should install the module in the NuGet PowerShell profile only once, no matter how many times I install the package (or invoke the command that registers the module). The init.ps1 in my fork currently auto-injects the PSBuild module in the NuGet profile, and only if not already present. After installation, the NuGet Powershell profile is reloaded (so the commands should be available now to the other packages being installed? to be verified). I considered Install-Package PSBuild as the explicit command. Also, init.ps1 is only called once: when loading the solution or when installing the package.
• As a dev I don't want to auto-enlist PSBuild as a package dependency if I package my consuming project. Making it a developmentDependency requires NuGet 2.8 (currently in beta): this would avoid consuming projects to list PSBuild as a dependency when the project is packaged.

Some stuff that can be accomplished today independent from the above:

• Informing the user about PSBuild being loaded in the profile when initializing the pkg manager console
• Some commands fail in the pkg manager console (likely because I forget to pass in params, such as project-path). Perhaps those parameter can be made optional and be derived from the project parameter?

from psbuild.

RE: How to create a NuGet pkg which has PS command that other NuGet pkgs can leverage via a NuGet pkg dependency

I have put together a sample in a gist at https://gist.github.com/sayedihashimi/8511756. There are two NuGet packages in this gist, sayed-module and consuming-module. sayed-module defines a new function New-Message inside of a PS module that is installed via init.ps1. consuming-module has a dependency on sayed-module and calls New-Message in it's install.ps1.

_Here is how to try out the sample_
You can build both using the build.ps1. After building the pkgs will be copied to c:\temp\nuget\localrepo\ you can setup a nuget local repo to that folder. Then use install-package consuming-module after that you should see that there is a message in the pkg manage console when consuming-module calls New-Message. Also you can call New-Message at this time as well.

More replies on your other comments coming later. Wanted to share this sample now though.

from psbuild.

Awesome! The gist verifies that dependent packages can inherit PowerShell functionality from another package, given the other package imports its module from within init.ps1.

FYI, you might also be interested in the following repository: https://github.com/peters/myget

from psbuild.

@xavierdecoster Were you still interested in this?

from psbuild.

I can still see the value in this (using psbuild in a PowerShell console that has knowledge about the current solution context can be interesting, eg Invoke-MsBuild )

from psbuild.

Ok I'm still working on it as well. If you are interested in contributing that would be great.

from psbuild.

Interested in contributing, but running a little short on time lately :( A short-list of smaller tasks might be a great help though

from psbuild.