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

[Jeff Forcier]

On Fri, Apr 17, 2009 at 9:39 PM, Paul Baumgart <address@hidden> wrote:
> 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'll be honest: I was kinda thinking the same thing (re factoring the
rsync bit out to its own function). I mostly resist such changes for
right now because I want to focus on getting this new version of
Fabric out before we start thinking about ways of chopping things up
further. (But, I *do* think there's a lot of room *for* such a
chopping up, immediately afterwards...)

> 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.

Well, the nice thing about the easy forking Github gives us is that
you don't really need anyone else's blessing on how to structure
things in your own version of the software (heck, how do you think I
got started with this? :D)

I think for now, leave yours as-is if you think that's the better way
to approach it, and when I start doing more reorganizing of the "non
core" functionality -- which is how I currently label the *_project
stuff -- I'll definitely be open to ideas, and I will actually be
explicitly asking for feedback at that point. Which will be soon :)

-Jeff

>
> 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
>>>>
>>>
>>
>