fab-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jeff Forcier
Subject: Re: [Fab-user] Setting custom variables on env, or in own dict?
Date: Sun, 10 Nov 2013 11:04:12 -0800

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


On Sun, Nov 10, 2013 at 8:17 AM, Paul Walsh <address@hidden> wrote:
> 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.
> _______________________________________________
> Fab-user mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fab-user



-- 
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]