Powershell: Rename build.psm1 and commands some of the commands

[lzybkr]

The module name is too generic, maybe BuildPowerShell.psm1?

And the prefix for commands in the module shouldn't be PS - that prefix belongs to the product, not the tool that builds the product.

Here are some possible names (with almost no real thought here):

Start-PSBootStrap => Start-BootstrapBuildPowerShell
Start-PSBuild => Start-BuildPowerShell
Start-PSPackage => Start-PackagePowerShell
Start-PSPester => Start-TestPowerShell -Pester
Start-PSxUnit => Start-TestPowerShell -xUnit

Assuming the above sounds good, some aliases are desirable too:

Start-BootstrapBuildPowerShell => sbbps
Start-BuildPowerShell => sbps
Start-TestPowerShell => stps

[vors]

My view on it:

• build.* is an expected and discoverable name
• the module is not a generic-purpose module (i.e. we never will publish it into a gallery), so distinct name is not needed.
• Same goes about the function names.
• Agree, we need to change PS prefix.
• Aliases like sbbps, etc make me sad.

[lzybkr]

I expect our build to be a pattern others follow, so we should keep that in mind.

build.psm1 is fine if you like the razzle model of a new shell for each project. I'm not sure that's what we want though.

Same goes for function names - Start-Build - fine if you create a new shell for each project you work in, but not so nice if you work in multiple projects.

[vors]

I see your reasoning. I don't like razzle model, but not that part of it.
It's ok to ask people run some command, when they switch context.
I.e. in python it's common to use virtualenvs.
You need to run a command to enter another virtual env, when you switch project.

Same way, it could be our pattern: we are using generic names (i.e build.psm1, Start-Build), just force-import the module, when you are switching context.

[andschwa]

You guys got me thinking about implementing a Make-like dependency system in PowerShell... it could work, and it would be awesome, especially with PowerShell being the first (real) cross-platform shell.

I'm also on the side of discoverability with build.psm1. I also realized too late back on Windows that PS was being used for PowerShell product cmdlets, heh.

[lzybkr]

Like https://github.com/psake/psake?

[andschwa]

That is awesome. @vors, our build module has gotten to the point that it's not simply a wrapper a any more. We've been talking about adding a Clean target, and we're having to do dependency checking. I think it makes sense to investigate using psake to clean it up.

[vors]

I tried psake and it lacks things that I expected. I.e error handing is non-intuitive (swallows exceptions silently).

On the other hand, there is an opportunity to influence the project.

[lzybkr]

Invoke-Build looks promising - the author also wrote a maml help file generator I considered using before PlatyPS.

[andschwa]

The reason I think we should move investigate these (and indeed Invoke-Build does look promising) is that we now have at least two pre-build tasks (type catalog generation and resource generation) as well as an upcoming post(?)-build task for crossgen/NGEN, and we want a clean task. Additionally we have xUnit, Pester, MSI, APPX, and Linux / OS X package creation targets.

Our needs are _definitely_ suited to a build tool.

[andschwa]

Oh and I forgot to list the native components too, as well as bootstrapping.

[andschwa]

Invoke-Build has VSCode integration. I think this is worth pursuing. I'll investigate.

[vors]

I would expect problems on Linux / CoreCLR, but definitely worth investigation.

[vors]

While we are on this thread, we also should pull things out of appveyor.yml into build.psm1 (or its replacement).

[andschwa]

@vors a fair bit of what's in appveyor.yml is already available in build.psm1. Check out what I do in the .travis.yml; I'm only calling our build functions.

[vors]

@andschwa most things there is capturing test results, reporting them and throwing, if there are failures. I agree that it should be moved to .\build.psm1

[andschwa]

@JamesWTruher was going to do that I think.

[andschwa]

It makes testing easier.

[nightroman]

Hello,

Sorry if this is off-topic or it is too late. The discussion was private and I
could not join it. I hope that Invoke-Build still can be useful.

@vors wrote:

I would expect problems on Linux / CoreCLR, but definitely worth investigation.

True, Invoke-Build currently has some known issues (like #31) and some
potential (like a few \ in paths). I am working on resolving them.

[nightroman]

Invoke-Build v3.0.1 is cross-platform with PowerShell v6.0.0-alpha.

[andschwa]

@nightroman that is awesome! Nice, fast, work. Our build module really should be rewritten in a target driven manner... random scripts are messy.

[joeyaiello]

I think we're far enough along here that this isn't going to be (nor does it need to be) changed. Closing unless someone has an issue with it.