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

[Jeff Forcier]

On Sun, Nov 23, 2008 at 12:38 PM, Nicolas Steinmetz
<address@hidden> wrote:

>> cd('workdir')
>> put('build/package.tar.gz', 'package.tar.gz') # saved inside the workdir
>
> if it means somehting like :
> cd workdir
> scp build/package.tar.gz server:/workdir/build/package.tar.gz,

My understanding of how this would be implemented, and I believe this
is what Christian meant too, is that the implicit path prefixing
*only* occurs on the *remote* end. So in this case, the first argument
to put() above would be relative to your local cwd (wherever you
called 'fab'), and only the second argument would be implicitly
updated (to 'workdir/package.tar.gz').

> Then, I'm not fan of it as it assumes you have the same directory structure
> on your deployment server and one the target server(s).
> Making the workdir implicit seems for me too magical and source of
> confusion.

This is definitely a good point; any time you have implicit behavior
instead of explicit behavior, it's magical, and makes it more likely
for users to become confused. The tug-of-war between the clarity of
explicitness vs the convenience of implicitness is tough sometimes,
especially for tools like Fabric which are inherently all about making
things more convenient (but written in a culture emphasizing
explicitness -- Python).

I think that as long as it's clearly documented that cd() operates
only on the remote paths, it wouldn't be too bad. We could put in an
'lcd()' too, at which point we're basically exposing your average FTP
concepts of remote/local cwd.

Wish there was a better way to handle all this; the main reason I'm
not just saying "just use variable names" is to make it easier to run
>1 command 'in' a directory via the "cd foo && run bar" approach, but
I'd love to come up with some elegant way that makes working with
paths easier overall. Need to think about it some more.

-Jeff