Repository navigation
Rename build.psm1 and commands some of the commands #1233
Description
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
Activity
vors commentedon Jun 29, 2016
My view on it:
build.*is an expected and discoverable namesbbps, etc make me sad.lzybkr commentedon Jun 29, 2016
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 commentedon Jun 29, 2016
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.andyleejordan commentedon Jun 29, 2016
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 commentedon Jun 29, 2016
Like https://github.com/psake/psake?
andyleejordan commentedon Jun 29, 2016
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.vors commentedon Jun 29, 2016
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 commentedon Jun 29, 2016
Invoke-Build looks promising - the author also wrote a maml help file generator I considered using before PlatyPS.
andyleejordan commentedon Jun 29, 2016
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.
andyleejordan commentedon Jun 29, 2016
Oh and I forgot to list the native components too, as well as bootstrapping.
andyleejordan commentedon Jun 29, 2016
Invoke-Build has VSCode integration. I think this is worth pursuing. I'll investigate.
vors commentedon Jun 29, 2016
I would expect problems on Linux / CoreCLR, but definitely worth investigation.
vors commentedon Jun 29, 2016
While we are on this thread, we also should pull things out of
appveyor.ymlintobuild.psm1(or its replacement).andyleejordan commentedon Jun 29, 2016
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.vors commentedon Jul 26, 2016
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.psm1andyleejordan commentedon Jul 26, 2016
James Truher (@JamesWTruher) was going to do that I think.
andyleejordan commentedon Jul 26, 2016
It makes testing easier.
nightroman commentedon Aug 22, 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:
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 commentedon Aug 23, 2016
Invoke-Build v3.0.1 is cross-platform with PowerShell v6.0.0-alpha.
andyleejordan commentedon Aug 23, 2016
Roman 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.
joeyaiello commentedon May 22, 2017
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.