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

[Niklas Lindström]

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
>