Re: [Fab-user] Completed suggestions: load and config (#1, #2, #3)

[Niklas Lindström]

Hi!

On Sat, Oct 25, 2008 at 1:32 AM, Jeff Forcier <address@hidden> wrote:
> Finally getting around to, you know, reading the stuff I asked Niklas
> to write out in the first place :) sorry for the delay!
>
> Regarding these first 3 changes: I like :)

No worries, a "delay" of some days aren't bad at all in a voluntary
open source effort IMO. Again, I'm happy. :)


> Looks like we're keeping get()/set() as well as the config object?
> That might be a good idea; I like the 'config' name for DEFAULT_ENV,
> because those values are "configuration" material. Doing something
> like "print config.fab_mode" has a nice sound to it.

That still makes the builtin "set" shadowed though, so I'd prefer to
remove them (perhaps deprecate them in the next release using the
"warnings" module), and then wipe them? Not the least to keep it
pythonic ("one obvious way to do it").


> But don't really like the idea of using it for
> *non-configuration-related variables*. In my mind there's a difference
> between "core" settings/configuration directives and a user's own
> namespace of information he wants to keep track of or pass between
> commands.
>
> So I'd actually be happy with what I assume is currently possible, a
> use case like this:
>
> def other_command():
>    # Using 'user' variable
>    sudo('rm -rf $(homedir)')
>
> def my_command():
>    # Doing something setting/config related
>    config.fab_mode = 'deep'
>    # Modifying 'user' variable
>    set(homedir='/home/jforcier')
>    # Using 'user' variable
>    if int(run('du -sm $(homedir)')) > 1024:
>        # This command (above) also uses a 'user' variable
>        other_command()
>
> If I read the code correctly, the above fabfile would actually be
> updating 'config' with that 'homedir' mapping, so the use of get/set
> is rather arbitrary. I'd almost like to add another dict to
> _new_namespace() so that config and user vars are physically separate.

You have a good point in keeping them separate. One could object that
it would "burden" the user, but I think it's correct since they affect
different things (fabric state and user state). How about a "fab"
Configuration object separate from "config"? I liked "config" better
than "var" in my own fabfiles, but if it doesn't ring well for "user
variables", any other name suggestions? That don't overshadow python
builtins.. ;)

Also this "fab" object would reasonably have some read-only
properties, like "fab.version" (yes, we'd drop "fab_" for keys in such
an object).

Best regards,
Niklas