Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Add command line flag for setting env vars #13
This used to be called
However, since I don't want to provide "builtin" tasks, best to do this as a flag, e.g.
Has same outstanding issue as task arguments re: setting non-string values (#69).
Originally submitted by Jeff Forcier (bitprophet) on 2009-07-21 at 11:44am EDT
Do you have any thoughts on how this should behave if a key-value pair is provided in
For example. Given
I think I favour overriding the existing env value ('robc') with the later value ('bob').
That's kind of tough. My instinct is the opposite of yours; I feel that the "specific" env-var-setting option should take precedence over the "generic" one.
Possible rationale: if somebody were actually in this situation and paying attention, they would've removed one or the other. Since they're now obviously not paying attention, they probably accidentally left the
Hard to argue with that logic :)
I had in my mind a scenario where a 'standard' fab command is used, and the
In this case, the value provided to
To be honest I think your argument has it. I'm also not sure it's that big a deal either way, as long as the behaviour is documented. And it's not unreasonable to expect the user to ensure their args don't conflict.
I think this issue scratches my itch.
I need to deploy the same system to various facilities. My solution was have a yaml file for each that stores the roledefs for the facility. Then say something like.
And load the appropriate role defs on demand based on the facility.
To do that I need a way to supply a script wide argument. My hacky work around is to use fabrc files that define the facility env var.
The NY config file would only contain:
With this suggestion I could do it with.
I don't have much experience with the code base but would be happy to take a look of you think it's a straight forward change.
I may have engaged my keyboard before my brain.
For my situation a config file is probably the best way to go, it can look like this:
I can then use callables in the roledefs to pull from the env.
Still happy to lend a hand if you need it, I'm enjoying using fabric.
@amorton Keep in mind that
Being able to tweak env vars from the CLI is still a valid feature to add, but for "config" type data, Python imports are always going to be more flexible than using flags :)
Good point about using an python import rather than config file.
It still leaves issue of supplying some information via the command line to identify the target env. In the short term I could supply "NY" as a role via the command line and then have callables in
@amorton -- Most folks currently solve that with a simple task that sets the appropriate env var(s). E.g.
def ny(): env.facility = "NY"
def facility(which): env.facility = which.uppercase()
I'm experimenting with this now:
It may be specified >1 time (as in,
It explicitly runs before any other flags are parsed, allowing any specific env-setting options to override anything updated with this one, as discussed above re: having specific override generic.
While the True-setting bit works, it's still avoiding a full implementation of #69. I feel this is a worthwhile temporary workaround because there is no other obvious valid interpretation of
This also works reasonably well for setting something to a False-equivalent value, provided one is testing that variable with