Re: Psake Changes

[James Kovacs]

Hi, Jorge,

Moving this over to psake-dev in case others have input... Hope that everyone had a good Xmas and New Years.

Some thoughts... (See below for Jorge's original ideas.)

1) Recursive builds - A few people have asked for them. If you can add support, fantastic!
2) Parameter for build properties - Sounds like a great idea.
3) Change property access - Not wild about changing how we access properties. I like the fact that I can basically paste a PowerShell script into a task and it works. Changing a local property to a script-level one (when you realize you need it more than once) is a simple copy/paste operation. I can think of two possible solutions... #1 Easy solution. Document variable collisions as a known issue and let people use their own naming conventions. #2 Harder solution and not even sure if it's possible. Save the defined properties before recursing into contained psake script and restore them on exit. Thoughts?

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)

On Sun, Dec 27, 2009 at 10:29 PM, Jorge Matos <matos...@gmail.com> wrote:

James,

 

There's a few changes I was thinking of adding to psake and would like your thoughts on it:

 

1) Recursive psake builds

       The abiltiy to have the Invoke-psake function be called from within a Task() function

 

2) Add a new parameter to the Invoke-psake function that allows you to set the values of properties in the build or add new ones

 

3) Change how properties are accessed in the build.  Currently properties are treated as script-level variables by using the "." operator:

 

    foreach($propertyBlock in $script:properties) 
    {
       . $propertyBlock
    }

 

which allows you to access a property in code very easily by its name, but in order to avoid property name collisions with recursive psake builds, I was thinking of

changing this so that properties are accessed only through a function that returns a hashtable so that the code does not access script-level variables, but instead must gain access to the property via the function. 

 

For example the "Properties" function could return the hashtable:

 

    Properties.ConnectionString

    Properties.SMTPServer

[Patrick van der Velde]

Hi All

On Mon, Jan 4, 2010 at 16:44, James Kovacs <jko...@post.harvard.edu> wrote:
> Hi, Jorge,
>
> Moving this over to psake-dev in case others have input... Hope that
> everyone had a good Xmas and New Years.

Not so much input but more support :)

>
> Some thoughts... (See below for Jorge's original ideas.)
>
> 1) Recursive builds - A few people have asked for them. If you can add
> support, fantastic!

Yes please :) We're currently running a modified version of Psake
because of this problem. I've offered to send Jorge a copy of our
version although I'm not sure it'll be very useful because it's really
really messy

> 2) Parameter for build properties - Sounds like a great idea.

That could be cool. We're not using them at the moment but I'm sure
they'll find a use when we do get them.

> 3) Change property access - Not wild about changing how we access
> properties. I like the fact that I can basically paste a PowerShell script
> into a task and it works. Changing a local property to a script-level one
> (when you realize you need it more than once) is a simple copy/paste
> operation. I can think of two possible solutions... #1 Easy solution.
> Document variable collisions as a known issue and let people use their own
> naming conventions. #2 Harder solution and not even sure if it's possible.
> Save the defined properties before recursing into contained psake script and
> restore them on exit. Thoughts?

Mmm I'd much rather prefer Jorge's solution, mainly because we've been
bitten one too many times by values that propagated between two build
levels while they shouldn't have. The same problem exists for include
files (although that may be a powershell problem). i.e. if you include
a script from a specific location then it will overwrite scripts with
the same name from different locations, even if those scripts were
imported at a different build level. Bugs due to this are very hard to
track down unfortunately. So yeah I'd prefer that the property thing
gets fixed properly.

Thanks

Patrick