On Sat, Jan 2, 2010 at 8:01 AM, Domen Kožar <do...@dev.si> wrote: > Hello @2010!
\o/ > Here is what I think multi-fab behaviour needs: > - easy (no boiler-plate code) integration between fabfiles > - less or no magic > - covers most use cases + scaling > - be Python > - override-able with parameter or/and default off > > First four are hard to achieve, but there is always an compromise. I > think this should be thought through very carefully. Agreed. As I said -- it's often a sliding scale with convenience/magic on one side and more-work/Pythonic on the other. Will have to see! > Another solution that seems more clean (and maybe opens Fabric's snippet > share) is to create an "fabric.snippets" namespace. Together with > templates for quick development of such packages we would create a wide > codebase. > So I would go and use "fabric.snippets.domen" package/module and fill it > it with functions/environment/whatever. This sounds a lot like something that came up earlier and was unresolved, using setuptools.pkg_resources to create this third party namespace so that one can install and import "fabric.something.whatever" independently of fabric.api/fabric.main/etc. I've cleaned up the "task namespacing" ticket with a mention of that approach and a link to where I found some discucssion on it; see the description here: http://code.fabfile.org/issues/show/56 So essentially, this issue (ability to load up >1 file's worth of tasks) touches on a few other semi-related features; we'll have to see where we end up going on it. Best, Jeff -- Jeff Forcier Unix sysadmin; Python/Ruby developer http://bitprophet.org _______________________________________________ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user