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

[Paul Baumgart]

One further argument in favor of splitting them up is that rsync()
becomes sort of an alternative to put(). My sense is that using
rsync_project() to upload a single file is a bit unintuitive.

I agree with your point that it's better to call the functions with
kwargs anyway, and if that's how most folks end up using it, the order
of parameters really doesn't matter. So, if you still disagree, I'll
update my code to make it 'forwards compatible' in case anyone wants
to use it in the meantime.

Paul

On Fri, Apr 17, 2009 at 6:12 PM, Jeff Forcier <address@hidden> wrote:
> 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
>>>
>>
>