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

[Niklas Lindström]

Hi,

I gave this some thought and came to the same conclusion as Christian
-- it's easier to work with the same namespace, and the 'fab_'-prefix
feels explicit enough. Especially since I use "@requires" for both
that one and user-defined names in a bunch of places.

Personally I do like `config`, I think of all in it as "configuration
variables". `vars` is also a builtin btw, and `var` didn't feel as
readable as `config`. `environment` or `env` might make sense though,
albeit I use that name for noting the target environment (staging,
production). I think that's rather conventional, so I'd prefer
`config` over e.g. `env` I think.

But I'm open for more debate. :)

Best regards,
Niklas



On Sat, Oct 25, 2008 at 10:58 PM, Christian Vest Hansen
<address@hidden> wrote:
> 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 :)
>>
>> Looks like we're keeping get()/set() as well as the config object?
>> That might be a good idea;
>
> I'm not so sure about that. The idea was, at least partly, to be rid
> of the `set` operation because it shadows the data-type of the same
> name. I just didn't go through and remove-slash-fold-them-into-config
> because there were so many other changes to look at.
>
>> 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.
>>
>> 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.
>
> ... which is currently done with the convention of having all
> fabric-internals related stuff prefixed with `fab_`.
>
> I don't like splitting this into two seperate namespaces for two
> reasons: 1) people risk setting `fab_` variables in their own
> namespace and 2) we'd have to decide on a name resolution order, might
> be different from what people expect and/or make it harder for them to
> reason about the code.
>
> Also, I actually don't see what the advantage would be to having these
> two namespaces.
>
>>
>> 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.
>>
>> -Jeff
>>
>
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>