I'm generally in favor, but there's a couple of things I'd like to comment on.
On Fri, Nov 21, 2008 at 10:51 PM, Jeff Forcier <[EMAIL PROTECTED]> wrote: > Hi all, > > Ran across this fabfile in IRC today: http://gist.github.com/27401. > > Not faulting the file itself (author knows it's not great) but I think > it would be nice to help users refactor their paths, and/or prevent > the sorts of hackery like on line 9 above. Stuff like 'run("cd > /foo/bar; do_stuff")' for commands that, for better or worse, need to > run from a certain location on the filesystem. Or, just generally > preventing a lot of repetitions of the same base path, as in lines > 18-25. > > These two problems overlap a lot, though not completely (i.e. in some > situations you DO need the full path, for e.g. symlinking a file > that's in a totally different directory tree) but I think that we can > still handle both with the same implementation: > > - Set up a new variable, 'cwd' or 'fab_cwd' (former is a bit shorter > which is good when the user needs to access its value directly; latter > is more in line with other fab-specific variables). For consistency sake, I'd go with `fab_cwd`. The world is simpler when rules don't have exceptions. > - Allow this variable to be set somehow (see below). > - Update run() and sudo() (and possibly local()?) to implicitly > prepend it to their commands, when it's non-empty. What about `put()`? I don't think the same thing that affects the working directory of `run()` and `sudo()` should also affect `local()` - it cannot be assumed that the two directory structures in the local and the remote world, are similar in any way. I think it should be a seperate variable for `local()` if we're going to have any. > - Probably with '&&', which is much safer than ';' -- imagine when > the user attempts to do the equivalent of "cd /var/www/mysite/subdir/ > ; rm -rf *", and then imagine that that directory does not exist. > Whoops, bye-bye home directory contents... I agree on this one. '&&' ftw. > > With such a setup, users can set the variable for certain blocks of > code (again see below) which obviates problem #1 (users having to > repeat calls to 'cd foo ; do something') and problem #2 (many of the > stuff in lines 18-25 could be simplified by factoring out > /var/www/eflorenzano.com and just running e.g. 'ln subdir/foo foo'; > and elsewhere, the user can just grab the value of 'fab_cwd' to build > parts of the command). > > > The main question is then how to control scoping of this. Ruby, > incidentally, has a leg up here due to how it allows lots of nested > anonymous code blocks. In Python, I think we have to either use the > brand-new-ish 'with' statement (2.5+ and 2.5 requires a __future__ > import) or fall back to semi ugly "flat" statefulness (i.e. calling > 'cd("/var/www")', running a few lines all "in" that dir, then 'cd("")' > to 'undo' it). How about relative paths? The unix command `cd` has a well understood behaviour with regards to relative paths, and I think people will assume that a `cd()` operation will work the same way. > > So, Python 2.5+: > > run('some command in my home directory') > > with cd('/var/www/'): > run('some other command that is now in /var/www') > run('yet another command in /var/www') > > run('final command, which is back in home directory') I think "with cd" reads bad, but on the other hand, I don't anybody will really notice. Sadly there's nothing we can do about `with`. > > Python 2.4-: > > run('some command in my home directory') > > cd('/var/www/') > run('some other command that is now in /var/www') > run('yet another command in /var/www') > > cd('') > run('final command, which is back in home directory') > > > Any comments/questions on all this? I'm not 100% committed to it -- > it's not THAT hard for users to just set a variable to the path prefix > and do the cd;command trick where necessary -- but I think it'd be a > nice tool to have. > > -Jeff > > > _______________________________________________ > Fab-user mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/fab-user > -- Venlig hilsen / Kind regards, Christian Vest Hansen. _______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
