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 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.
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
_______________________________________________
Fab-user mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fab-user
