psake update

[Jorge]

I've been reading the posts lately and I get the sense that it would
be better to not have psake as a module because you are required to
use the Import-Module function before you can use it.

psake was originally written as a script called psake.ps1, this was
before psake was re-done for PowerShell V2 - I was the one responsible
for this change and I thought at the time I needed to have psake live
in a module in order to use advanced functions - I was mistaken.

So I've re-written psake to not require a module but it still uses
advanced functions - so you still get integrated help support and tab
completion.

The only downside is that you can't easily remove psake using the
remove-module function.

The new psake code is in a branch: http://github.com/JamesKovacs/psake/tree/experimental-no.psm1

It's a first draft but it passes all the specs.

You have 2 ways to run your build

1) Dot-Source the psake.ps1 file and call Invoke-psake

> . .\psake.ps1
> Invoke-psake .\default.ps1 Clean

or

2) Call the psake.ps1 script directly

> psake.ps1 .\default.ps1 Clean
- parameters will get passed to the Invoke-psake function

What I would like is feedback on this new version - is a good idea?
or should we stick with the module?

--
You received this message because you are subscribed to the Google Groups "psake-dev" group.
To post to this group, send email to psak...@googlegroups.com.
To unsubscribe from this group, send email to psake-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/psake-dev?hl=en.

[Eric Hexter]

I really do not see a difference in using a module versus a dot sourced script.  What I mean by that in more concrete terms is this example http://codecampserver.codeplex.com/sourcecontrol/network/Show?projectName=codecampserver&changeSetId=836d93c490a2#psake.bat

 

This shows referencing and loading the module into powershell.  The big goal of most developers is that they want xcopy deployment and to include all the tools in their source tree.  I think the push back on the module is more of not understanding how to load it in a new powershell session and being able to run it.  It may be better to include a bootstrapped batch file like this one which developers can add to their source tree to be called by continuous integration servers, instead of backing psake out of the module and putting it back into a dot sourced script.  I was a little worried when you first put it into a module but, that was becuase I did not understand how to use it in powershell the way I wanted to use it.  Others led the way and I just pulled it together in this batch file.

 

Long story short is... I think you can deal with the complaints by 1. including the bootstrapping in the source tree of psake. 2. adding a quick guide on how to use it in the FAQ.  3. Address the Why is this a Module in the FAQ as well.

 

To me it seems like most v2 powershell scripts I am coming across are modules so it seems like the way it should be done. I am really not a powershell expert so unless there is another reason to move away from the module, other than what I have stated here I would say keep it as it is.  The more churn you put into the main project that more it hurts adoption.

Eric Hexter

Director of OSS | Headspring | www.Headspring.com
email | ehe...@Headspring.com
blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter

[Jorge Matos]

The code in the new branch just has one main script "psake.ps1" and you still have integrated help, tab-completion and support for named parameters.

 

> Get-Help .\psake.ps1 -Full
   - this will show you help and examples of how to use psake

> .\psake.ps1 

  - This will execute the "default" task in the "default.ps1" in the current directory

> .\psake.ps1 .\examples\default.ps1
  - This will execute the "default" task in the "default.ps1"

> .\psake.ps1 .\examples\default.ps1 Clean
   - will execute the "Clean" task in the default.ps1 script

> .\psake.ps1 -buildFile .\examples\default.ps1 -framework '4.0'
  - supports named parameters

 

The only drawback that I can see is that the $psake variable does not go away after the script completes - where with a module - all module variables are removed when you use the Remove-Module function.

 

I agree that too much churn is not good for adoption - but if this makes psake easier to use then that would help adoption - don't you think?

 

If the consensus is to keep the module then that's okay with me, but I would ask that folks please review the code in psake.ps1 in the new branch before making a decision.

 

I really really really appreciate your feedback Eric.

--
Jorge Matos
Senior .NET Architect, MCSD.NET, MCSD Visual Studio 6.0
(440) 666-3107
matos...@hotmail.com      
Blog: http://jorgelmatos.blogspot.com
--------------------------------------------------------------------------------
"Any intelligent fool can make things bigger and more complex...
It takes a touch of genius - and a lot of courage to
move in the opposite direction."... - Albert Einstein