fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] How is config file merged into environment?


From: Jeff Forcier
Subject: Re: [Fab-user] How is config file merged into environment?
Date: Sat, 27 Jun 2009 10:30:52 -0400

On Sat, Jun 27, 2009 at 9:42 AM, Steve Steiner<address@hidden> wrote:

> I think Python 2.6 is the difference.  I need the multiprocessing package so
> have to use 2.6.  2.5 is sooooooooo, '06... ;-)

Ah, yes, that would certainly do it. Sadly there's nothing we can do
about that particular warning outside of maintaining a fork of
Paramiko. Which would solve a number of minor issues and allow Fabric
to be a little cleaner, but I'd rather not ;) forking is not something
to be done lightly.

I do have 2.6 support listed as a TODO item, FYI, so any 2.6 related
stuff that we *do* have control over, would certainly be fixed if
found.

> But a simple:
>
> host = "xxx.yyy.zzz.kkk"
>
> Or:
>
> hosts = xxx.yyy.zzz.kkk

Unfortunately, neither of those would work: env.hosts has to be a
list, so the latter example you give is equivalent to setting it to
the string "xxx.yyy.zzz.kkk", which naturally would mean the host list
is ['x', 'x', 'x', '.', 'y', ...]. Not exactly what you had in mind :(

> Right, and producing a dictionary.
>
> Then the "env" dictionary is update()d from that.  So the value from the
> config should overwrite/get added to the env dict, no?

Correct, but see above for why I think it's not working correctly.


> There doesn't seem to be any doc on the whole command line util which is how
> I mostly use fabric, at this point.

There sort-of is:

    http://docs.fabfile.org/api/main.html

but it's really just explaining fabric.main; some of the sections
(docstrings) in this page go over how fabfiles are located and how
args are parsed. When I go over the docs (RSN) I'll probably
experiment with updating that page from "just autodocs/API" to "prose
documentation with occasional autodoc docstrings inserted within".
Including documenting all the CLI options (possibly just printing out
what you see in --help -- you *do* know about --help I hope :D) and
config files and etc.

> How's that bug tracker coming...stupid TODO...

It's coming along well. Doing another "release" with a bunch of
changes, at work, early next week. After that I'll start looking at
deploying it to the Fab server.


>From another email, still Steve:

> Jeff -- what about adding some special handling for --hosts files?  Seems like
> a _very_ common use-case and would be a piece of cake to implement either
> modifying the existing handler or using Jordi's code if it actually does
> something different.

I'd be up for that, but probably only if the config file doesn't get
more intelligent, which I think is a better idea -- it's more
generally useful but still fills the same need. I.e. a "hosts file"
could just be a config-file-formatted file that sets env.hosts, and
specified with --config. (The logic used to merge conf file contents
with command-line options would definitely be looked at, too, because
merging probably is a better idea than overwriting.)

-Jeff




reply via email to

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