Re: [Fab-user] RFC: Implementing a current working directory / path refactoring feature

[Christian Vest Hansen]

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 <address@hidden> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.