Feature Request - leverage command line properties within script properties

[Jason Jarrett]

Not sure how possible this is (or if it even makes sense in the bigger picture of the project), but would love to reference command line properties variables within scripts properties block?

I hope this sounds useful and I'm not trying to do something crazy here...

properties {

#NOTE: the $buildConfiguration should be passed in through the command line parameters

# would be nice to leverage those here...

$buildOutputDirPath = ".\Build\$buildConfiguration"

}

I've attached a spec repro to reference if this sounds like a feature that could be added.

Any thoughts?

[Jorge Matos]

Jason,

 

Command-line parameters are processed after the properties in the build script are processed so what you want to do can't be done without re-writing the invoke-psake function.  That being said I'm not opposed to having the command-line parameters processed before the script properties.

 

I would like to get feedback from other users and developers from this group before I make the change though.

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

[Joshua Poehls]

At least in my scripts, having the command-line parameters processed before the script properties would not introduce any breaking changes.

 

I can definitely see the usefulness of being about to use the command-line params when initializing the script parameters. This would also seem more consistent with how other build tools work. +1

- Joshua Poehls

[zi makki]

+1

Sent from my iPhone

[Dusty Candland]

+1

[James Allen]

+1

Although, the original example of having a build output path variable
($buildOutputDirPath = ".\Build\$buildConfiguration") is the only
scenario I can see this coming in useful. But I reckon still worth
implementing!

On Mar 10, 3:51 pm, Dusty Candland <candl...@gmail.com> wrote:
> +1
>
>
>
> On Wed, Mar 10, 2010 at 7:31 AM, zi makki <zima...@gmail.com> wrote:
> > +1
>
> > Sent from my iPhone
>

> > On 10 Mar 2010, at 02:28 PM, Joshua Poehls <jdpoe...@gmail.com> wrote:
>
> > At least in my scripts, having the command-line parameters processed before
> > the script properties would not introduce any breaking changes.
>
> > I can definitely see the usefulness of being about to use the command-line
> > params when initializing the script parameters. This would also seem more
> > consistent with how other build tools work. +1
>
> > - Joshua Poehls
>

> > On Tue, Mar 9, 2010 at 10:47 PM, Jorge Matos < <matos.jo...@gmail.com>
> > matos.jo...@gmail.com> wrote:
>
> >>  Jason,
>
> >> Command-line parameters are processed after the properties in the build
> >> script are processed so what you want to do can't be done without re-writing
> >> the invoke-psake function.  That being said I'm not opposed to having the
> >> command-line parameters processed before the script properties.
>
> >> I would like to get feedback from other users and developers from this
> >> group before I make the change though.
>

> >>  *From:* Jason Jarrett <sta...@gmail.com>
> >> *Sent:* Monday, March 08, 2010 2:40 PM
> >> *To:* psake-users <psake...@googlegroups.com>
> >> *Subject:* Feature Request - leverage command line properties within

> >> script properties
>
> >> Not sure how possible this is (or if it even makes sense in the bigger
> >> picture of the project), but would love to reference command line properties
> >> variables within scripts properties block?
>
> >> I hope this sounds useful and I'm not trying to do something crazy here...
>
> >>  properties {
> >> #NOTE: the $buildConfiguration should be passed in through the command
> >> line parameters
> >> # would be nice to leverage those here...
> >> $buildOutputDirPath = ".\Build\$buildConfiguration"
> >> }
>
> >> I've attached a spec repro to reference if this sounds like a feature that
> >> could be added.
>
> >> Any thoughts?
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "psake-users" group.
> >> To post to this group, send email to <psake...@googlegroups.com>
> >> psake...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> <psake-users%2Bunsu...@googlegroups.com>

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

> >> <psake-users%2Bunsu...@googlegroups.com>

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

> > psake-users...@googlegroups.com<psake-users%2Bunsubscribe@googlegr­oups.com>

> > .
> > For more options, visit this group at

> >http://groups.google.com/group/psake-users?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Patrik Akselsson]

I see command line parameters as a way to override default values. I.e. we have a shared build script with default value for target directory, but team members can change that value by adding properties to the command line. Would that work if command line properties were invoked before script properties? It would be great if PSake would continue to support this scenario.

With kind regards

Patrik Akselsson

[Eric Hexter]

I am actually working through this same issue this week..  In some CI cases I want to override a property from the command line. I NAnt I handled this by making my properties Override=false .. So if the propety was set from the command line than do not set it from within the script. 

 

How does this translate into psake?  Not totally sure, but having access to the command line properties from within the params section could allow from some conditional logic.

 

so

 

+100 on this one.. It would be really useful.

 

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

[James Kovacs]

I have no problem with this change as long as we can support both scenarios mentioned:

1. Overriding psake parameters via the command line. (Currently works.)
2. Using command line parameters to define psake parameters. (Not implemented.)

If we can ensure that both scenarios work properly, I am good with the change. If we can only get one working, I would prefer to keep the current functionality of allowing the command line parameters as overrides. Always open to further discussion, of course.

BTW - I've added an issue for this on the Google Code site. (http://code.google.com/p/psake/issues/detail?id=17)

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

[Jorge Matos]

In my last commit i added a new parameter to invoke-psake called "properties" that takes a hashtable - it works in a similar way as the "parameters" parameter, except that it is processed after the scripts properties function has been dot-sourced - which means that you can over-ride the value of a property you have in your build script.

 

So in the scenario where you want to reference a parameter from within your properties function, you should use the "parameters" parameter, but when you want to over-ride a property in your build script use the "properties" parameter.

 

ex.

invoke-psake default.ps1 -parameters @{"buildenv"="dev"} -properties @{"p1"=100}

 

defualt.ps1

----------------

properties {

    $build_dir = "c:\\"

    $build_output_dir = "$build_dir\$buildenv"

    $p1 = 0 

}

task default -depends test

 

task test {

  assert {$build_output_dir -eq "c:\\dev"} '$build_output_dir was not set correctly'

  assert {$p1 -eq 100} '$p1 was not 100'

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

[James Kovacs]

Excellent solution, Jorge. This will work both for people who want to feed values into the script and override properties. Thanks!

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