[Fab-user] Setting custom variables on env, or in own dict?

[Paul Walsh]

Hi again,

I've come up against this myself a few times, again, a question of "best practices".

I use a configuration object of my own `CONFIG` throughout my package of fab tasks. But I continue to be bugged as to whether I should simply put all my config directly onto `env`. From the docs, I'm honestly not sure if the recommendation is for or against it. Quoting:

"This aspect of env is largely historical: in the past, fabfiles were not pure Python and thus the environment was the only way to communicate between tasks.

Nowadays, you may call other tasks or subroutines directly, and even keep module-level shared state if you wish.In future versions, Fabric will become threadsafe, at which point env may be the only easy/safe way to keep global state."

And then I see that in Invoke/Fabric 2, the end object won't exist.


Is there any current best practice in the community on this?

An example:

CONFIG = {
'staging': {'machine_location': '123.545.232.67', 'machine_port': 80},
'production': {'machine_location': '123.454.232.24', 'machine_port': 443},
}

In some places I'll merge this with values from `env` too, for example, when I set env.user to be owner of a process.

Any advice is appreciated.

Thanks,

Paul.

[Jeff Forcier]

Hi Paul,

There really is no best practice - it comes down to personal coding
style, what works best for your situation & how your fabfile is
managed. Fabric tries to be 'just Python' in this regard.

For single-module fabfiles it doesn't matter because you can simply
define at top level & refer throughout, as with your example.

When your fabfile gets larger & spread out among multiple files, then
riding on top of fabric.env is an easy way to share that info across
files because most of them will naturally be importing fabric.env
anyway. But not required - could just as easily namespace under your
own module instead (e.g. 'from base import CONFIG' or whatever.)

And yes, Fabric 2 will largely do away with global shared state and
encourage saner configuration & data passing practices. Details are
still being figured out but at the least it'll use an env-like
'context' object which is passed into functions explicitly instead of
being reference from global scope.

Best,
Jeff

Post by Paul Walsh
Hi again,
I've come up against this myself a few times, again, a question of "best practices".
I use a configuration object of my own `CONFIG` throughout my package of fab tasks. But I continue to be bugged as to whether I should simply put all my config directly onto `env`.