fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] Re: Specify what directory should be rsynced


From: Jeff Forcier
Subject: Re: [Fab-user] Re: Specify what directory should be rsynced
Date: Fri, 17 Apr 2009 21:12:20 -0400

I'm not convinced that splitting it into 2 functions is worth it
simply to avoid having to shuffle argument order around a little bit
or use kwargs. In fact, in my experience, your 2nd "bad" option
(specifying everything as kwargs when calling the function) is
actually the most readable and explicit way to use functions where
most arguments are keyword arguments.

Not sure if you saw my modifications in magic-removal, but they're here:

http://github.com/bitprophet/fabric/blob/9e2cbe48caa2b75c0b6347a373c05b18104775e1/fabric/contrib/__init__.py#L13

-Jeff



On Fri, Apr 17, 2009 at 8:52 PM, Paul Baumgart <address@hidden> wrote:
> So, here's my attempt:
> http://github.com/paulbaumgart/fabric/blob/0b1599e457076bcba31d5a400e1227a4cf93522e/fabric.py#L670
>
> My reasoning behind dividing it up into two functions, rsync() and
> rsync_project() was threefold:
> -Having a default value for the localpath parameter would mean it
> would either have to come after the remotepath (unintuitive), or force
> users to use only kwargs when not specifying a localpath (klunky).
> -It maintains the nice symmetry with upload_project().
> -It's backwards compatible.
>
> Thoughts? :-)
>
> Paul
>
> On Fri, Apr 17, 2009 at 1:18 PM, Jeff Forcier <address@hidden> wrote:
>> For what it's worth, I've just added a 'local_dir' option to my port
>> of rsync_project in the magic-removal branch, so when that goes out
>> the door it will have that option in place :)
>>
>> -Jeff
>>
>> On Thu, Apr 16, 2009 at 11:56 AM, Jeff Forcier <address@hidden> wrote:
>>> On Thu, Apr 16, 2009 at 11:31 AM, Wes Winham <address@hidden> wrote:
>>>> For my particular case, I started out using a bzr lightweight check
>>>> and bzr up to do those updates, just as you would expect. There were a
>>>> few issues that eventually convinced me that was not the best for my
>>>> case:
>>>>
>>>> <snippity-snip>
>>>>
>>>> I hope that makes sense.
>>>> -Wes
>>>
>>> Yea, that made sense, and it sounds like you're definitely hitting a
>>> bunch of the scenarios I alluded to :)
>>>
>>> -Jeff
>>>
>>>> On Thu, Apr 16, 2009 at 11:00 AM, Jeff Forcier <address@hidden> wrote:
>>>>> On Thu, Apr 16, 2009 at 10:52 AM, Wes Winham <address@hidden> wrote:
>>>>>> I'm super excited about how much rsync is going to speed up my
>>>>>> deployment process when I'm just applying small changes. Thanks for
>>>>>> the awesome work.
>>>>>
>>>>> Call me silly, but isn't this what version control is for? Maintain a
>>>>> checkout of your release branch (or a release tag) and then just do
>>>>> e.g. "svn up" (or "svn switch") during your deploy process.
>>>>>
>>>>> I'm sure there are plenty of scenarios where that doesn't work, but
>>>>> for the common case it seems to be widespread enough to be considered
>>>>> best practices *shrug*
>>>>>
>>>>> At any rate, I'm definitely all for adding flexibility to the builtin
>>>>> tools like rsync_project -- so don't think I'm poo-pooing that! --
>>>>> just curious what it may offer over what I'm personally used to.
>>>>>
>>>>> Best,
>>>>> Jeff
>>>>>
>>>>> P.S. Still cranking away on magic-removal, been relatively busy lately
>>>>> but hoping to get back on it full-steam soon!
>>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Fab-user mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/fab-user
>>
>




reply via email to

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