Repository navigation
Rename build.psm1 and commands some of the commands #1233
Description
Activity
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.
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.
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.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.- Reacted by Keith HillReacted by Andy Jordan
That is awesome. sergei (@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
Cleantarget, and we're having to do dependency checking. I think it makes sense to investigate usingpsaketo clean it up.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.
Reacted by Andy JordanInvoke-Build looks promising - the author also wrote a maml help file generator I considered using before PlatyPS.
Reacted by Andy JordanThe 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.
Oh and I forgot to list the native components too, as well as bootstrapping.
Invoke-Build has VSCode integration. I think this is worth pursuing. I'll investigate.
I would expect problems on Linux / CoreCLR, but definitely worth investigation.
While we are on this thread, we also should pull things out of
appveyor.ymlintobuild.psm1(or its replacement).sergei (@vors) a fair bit of what's in
appveyor.ymlis already available inbuild.psm1. Check out what I do in the.travis.yml; I'm only calling our build functions.Andy Jordan (@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.psm1James Truher (@JamesWTruher) was going to do that I think.
It makes testing easier.
- modified the milestone:
on Aug 4, 2016 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.sergei (@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.Reacted by Andy JordanInvoke-Build v3.0.1 is cross-platform with PowerShell v6.0.0-alpha.
Reacted by Andy JordanRoman Kuzmin 1967-2026 (@nightroman) that is awesome! Nice, fast, work. Our build module really should be rewritten in a target driven manner... random scripts are messy.
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.
Reacted by Andy Jordan
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