[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fab-user] Fabric setuptools plugin prototype
From: |
Christian Vest Hansen |
Subject: |
Re: [Fab-user] Fabric setuptools plugin prototype |
Date: |
Sun, 9 Mar 2008 20:22:32 +0100 |
Hi Rob,
You use git-format-patch for creating patches with git. Doing this
should make it easy to apply the patch with git-am.
I've just got your mail and haven't look at the code so I got no
comments on that.
On 3/9/08, Rob Cowie <address@hidden> wrote:
> Hi Christian,
>
> I haven't figured out how to do diffs with git, so until then...
>
> I've posted a diff to snipplr (http://snipplr.com/view/5340/)
>
> The changes thus far are:
>
> * Import pkg_resources
> * Addition of an entrypoint mapping (maps application entrypoints
> (strings) to Fabric registries)
> * Addition of a load_plugins() function.
> * load_plugins call in main()
>
> load_plugins() is responsible for using pkg_resources for searching
> sys.path, os.getcwd(), and any additional paths passed for
> "distributions".
> A "distribution" is a python module/package/egg identifiable by
> setuptools. From this list of distributions, we can search for
> packages that expose callables registered to our entry points (in this
> case, fabric.operations, fabric.commands, and fabric.strategies).
>
> I'm not convinced that my choice of plugin entry points is a good one.
> It might be better to provide one entry point (say fabric.plugins) and
> have the application code discover what 'type' of callable is made
> available.
>
> Oh... the diff also includes an additional prompt() operation, simply
> because I forgot to remove it! It also includes some extraneous print
> statements, also because I forgot about them.
>
> All that remains is to create a plugin, register entrypoints in
> setup.py, package it as an egg and either install it in the PYTHONPATH
> or drop it into the same directory as the fabfile.
>
> I've attached a stub Subversion plugin. It exposes two functions that
> will be registered as fabric operations; svn_checkout, svn_export.
> Neither does anything except print to stdout.
>
> Your idea of passing the current fabric 'context' to every plugin
> callable is a good one. I haven't implemented this.
>
> Attached is an egg which - with any luck - will make these two
> operations available if you install it.
>
> Rob C
>
>
>
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>
>
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.