fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] Completed suggestion: decorators (#4)


From: Christian Vest Hansen
Subject: Re: [Fab-user] Completed suggestion: decorators (#4)
Date: Sat, 25 Oct 2008 23:22:08 +0200

I've been meaning to create something like State and move from
fabric-the-module to fabric-the-package for quite some time but just
never got around to it. So this approach has a +1 from me :)

On Sat, Oct 25, 2008 at 11:14 AM, Niklas Lindström <address@hidden> wrote:
> Nice that you like it. :)
>
> I agree that we need a refactoring. I'd like to start that with
> something like this:
>
> * create a "State" class, with one global instance via which all the
> stuff that uses current state operate.
> * add unittests for at least all the operations.
>
> After that it'd feel safer to turn fabric into a package of modules.
>
> Also note that I'm thinking in small steps regarding "State" -- it's
> reasonable to think of a "Fabric" class which all the operations are
> either methods of, or registered like today, but takes a Fabric
> instance as first argument and are exposed as partials
> ("functools.partial(fabric, operation)"). But I'd begin with just
> centralizing the state (and making a "fabric.reset()" to facilitate
> unittesting).
>
> If I have time this weekend, I'll take a stab at this. and if so post
> it as one of these "Completed suggestion" mails -- albeit I'll drop
> the numbering and just use a name. ;)
>
> Best regards,
> Niklas
>
>
>
> On Sat, Oct 25, 2008 at 2:46 AM, Jeff Forcier <address@hidden> wrote:
>>> == 4. Decorators ==
>>
>>> My added decorators are for calling `require` and ìnvoke` prior to the
>>> decorated command. These also work with the new inspection of
>>> `command.func_code` to trigger `connect` (see
>>> `_new_operation_decorator` and `_needs_connect`).
>>
>> Thumbs up here too :)
>>
>> Somewhat unrelated: as I was looking at this code and related stuff
>> (some of which is Christian's I believe), it's getting really obvious
>> that fabric.py is turning into functional programming soup. I know
>> we've had a refactoring / reorganizing in the wings for a while; I may
>> take a stab at that for my next dig at the code, whenever that is.
>>
>> I.e. I'd like fabric.py to be a lot more straightforward, with many of
>> the helper methods in another file(s) somewhere (and possibly renamed
>> so they're not all starting with underscores, which IIRC is one of the
>> benefits of having exterior library files).
>>
>> -Jeff
>>
>
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>



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

reply via email to

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