properties override #46

Closed
galaktor opened this Issue Jul 30, 2012 · 3 comments

Projects

None yet

2 participants

@galaktor

Not sure how easy this would be to do, but today I discovered something unexpected regarding "-properties".

When I define two paths in my properties block like so:

properties {
    $base_dir      = "some\path"
    $src_dir        = "$base_dir\src"
}

...and I want to change base_dir via command line override, like so:

Invoke-psake .\script.ps1 -properties @{"base_dir"="a\nother\path"}

...then src_dir will still use the original value of base_dir ("some\path"). When I change base_dir via the command line I would expect that to affect all other properties that use the property.

My guess is that psake literally modifies the properties I pass via the command line, but by then all the other ones have already been initialized with the defaults.

Implementing this might be trickier than it sounds, but I do think it would be extremely useful. At the moment I work around it by re-building variables (mostly paths) before they are used in different tasks. I would love to be able to move them to a more global scope, like the properties.

A (naive?) idea off the top of my head would be:
When initialising the property block from the script (= the default values), always check if there is an override provided for the property at hand on the command line. If there is, use that instead of what it would default to in the script. Following initialisations would then use the command line value rather than the one from the script.

When I get some time I'll see if I can fork and try it myself, but I'm a bit of a powershell rookie.

Otherwise, while I'm at it: thanks for the great tool! Loving it.

@jmatos
Member
jmatos commented Jul 30, 2012

I think you may need to use the -parameters feature:

https://github.com/JamesKovacs/psake/wiki/How-can-I-pass-parameters-to-my-psake-script%3F

On Mon, Jul 30, 2012 at 9:13 AM, galaktor <
reply@reply.github.com

wrote:

Not sure how easy this would be to do, but today I discovered something
unexpected regarding "-properties".

When I define two paths in my properties block like so:

properties {
$base_dir = Resolve-Path ..
$src_dir = "$base_dir\src"
}

...and I want to change base_dir via command line override, like so:

Invoke-psake .\script.ps1 -properties @{"base_dir"="a\nother\path"}

...then src_dir will still use the original value of base_dir. When I
change base_dir via the command line I would expect that to affect all
other properties that use the property.

My guess is that psake literally modifies the properties I pass via the
command line, but by then all the other ones have already been initialized
with the defaults.

Implementing this might be trickier than it sounds, but I do think it
would be extremely useful. At the moment I work around it by re-building
variables (mostly paths) before they are used in different tasks. I would
love to be able to move them to a more global scope, like the properties.

A (naive?) idea off the top of my head would be:
When initialising the property block from the script (= the default
values), always check if there is an override provided for the property at
hand on the command line. If there is, use that instead of what it would
default to in the script. Following initialisations would then use the
command line value rather than the one from the script.

When I get some time I'll see if I can fork and try it myself, but I'm a
bit of a powershell rookie.

Otherwise, while I'm at it: thanks for the great tool! Loving it.


Reply to this email directly or view it on GitHub:
#46

@galaktor

Wow, I never realized there was a difference between -parameters and -properties! I thought -parameters was deprecated in favor of -properties or something, since when I tried -parameters I remember it not working for me (for some reason I cannot remember). I will give it another try, hope it will work!

@galaktor

This worked for me. It's still not ideal, because I can only either declare something as a param or a property. But it helped me achieve what I wanted, so cool.
Thanks!

@galaktor galaktor closed this Jul 31, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment