fab-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: [Fab-user] RFC: Implementing a current working directory / path ref


From: Jeff Forcier
Subject: Fwd: [Fab-user] RFC: Implementing a current working directory / path refactoring feature
Date: Sat, 22 Nov 2008 11:31:45 -0500

On Sat, Nov 22, 2008 at 4:37 PM, Jeff Forcier <address@hidden> wrote:
> On Sat, Nov 22, 2008 at 8:22 AM, Christian Vest Hansen
> <address@hidden> wrote:
>
>> What about `put()`?
>
> I don't use put() often yet so of course it slipped my mind :) I could
> go either way; there's a number of small things that bother me about
> applying fab_cwd to put() (biggest probably that it's not something
> that actually applies in "real world" usage: you always have to use
> absolute paths with e.g. scp) but on the other hand, it could be
> pretty useful and not _too_ much of a metal stretch for users used to
> normal scp/shell usage.
>
> What are your own thoughts on put()?

I think it should affect put().

When you upload files, you generally do so because you want to run
commands that work with/on them. A bit like this, for instance:

cd('workdir')
put('build/package.tar.gz', 'package.tar.gz') # saved inside the workdir
run('tar -xzf package.tar.gz')

>
>> 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.
>
> Yea, definitely. Off the top of my head, simply using os.path methods
> (assuming one can't ever SSH to windows systems...? I've never tried
> on anything that wasn't running Cygwin) should handle that fine,
> right? e.g. if fab_cwd was equal to '/var/www/foo/bar' and one did
> cd('../../'), we could do os.path.abspath(os.path.join(fab_cwd,
> new_cwd)) to get '/var/www'.

Sounds like the way to go. Who runs Windows on a server anyway? ;)

>
>> 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`.
>
> After thinking about it, I'm actually starting to lean *away* from
> using `with` -- though if we did use `with`, renaming cd to cwd (just
> thought of this) makes much more sense: "with cwd('foo')" sounds way
> better IMO.
>
> But, using 'cd' as a normal command/function has a lot of pluses: no
> worries about Python 2.4 support, feels more natural from a "I am
> shell scripting" standpoint (command, command, cd /var/www, command,
> cd ../log, command) and so forth.
>
> If I were adding this feature to Capistrano I think a block would make
> sense because that's a Ruby idiom; but it's NOT a Python idiom, even
> after the addition of `with`, which isn't really for setting extra
> state as much as controlling enter/exit for purposes of cleanup (as
> far as I've read). I should try to keep my Ruby out of my Python :)

[Note to self: Haskell too.]

>
> What do you think? Is it worth trying to set up 'with cwd'; do we just
> go with normal command 'cd'; or (don't think this is really a great
> idea) do both?

I think just normal 'cd' will do.

Not only is the pain/gain ratio better, but the `with` idea
practically mandates having both (the two-names vs.
one-overloaded-name question notwithstanding), because we also want to
support Python 2.4 as much as possible.

>
> -Jeff
>



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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]