Hello @2010! I see there is interest about multi-fab implementation. I agree that my solution with traversing is auto-magical and may lead to strange behaviours and hard debugging.
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. Cons for using traversing: - magic (needs good documentation) - unsuable in chrooted environment - ... more? 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. Options integrating this in Fabric are endless (since we are finally doing Python). For example one could do Fabric --lib domen -l or still easily force it in fabfile.py: from fabric.snippets.domen import * Feedback is appreciated;) Greetings, Domen On Wed, 2009-12-30 at 13:58 -0500, Jeff Forcier wrote: > Hi all, > > I've updated http://code.fabfile.org/issues/show/122 since it seemed > relevant to this discussion. > > The most obvious solution seems to be to make ~/.fabricrc a full > fabfile of sorts and to simply process it prior to loading the "main" > (per-project / based on user's cwd) fabfile. (Or leave it alone and > additionally auto-search for a ~/.fabfile.py or similar.) > > We could also change the logic so it no longer stops at the first > fabfile but searches up to filesystem root and loads all found > fabfiles in reverse order (so the "closest" fabfile overrides "farther > away" ones.) This sounds closer to what Domen wants, and is possibly > cleaner than the "home dir + local" approach in the previous > paragraph. > > (Steve, is your .fabrc solution different from either of those? is it > documented anywhere? I don't recall seeing it previously...) > > The major problem with any multiple-fabfile approach, however, is that > it can break the ability to understand a given fabfile just by reading > it, because -- once http://code.fabfile.org/issues/show/21 is > implemented to allow calling of tasks by name -- the internal mapping > of task names/objects will have >1 fabfiles' worth of tasks in it. > > This makes me kind of uncomfortable, though I realize how useful it > could still be. It's one of those things where I have to balance > "magical" usefulness against "non-surprising" naivite. > > Thoughts welcome :) > > -Jeff > > On Wed, Dec 30, 2009 at 11:04 AM, Steve Steiner (listsin) > <list...@integrateddevcorp.com> wrote: > > > > On Dec 30, 2009, at 10:48 AM, Domen Kožar wrote: > >> Current solution: > >> Import my "global project fabfile" from /home/user/code/fabfile.py in > >> every project. > > > > I do the same thing, only from a ~/.fabrc directory (or something like > > that, I forget). I remember there was some talk about adding this but I > > didn't pay much attention because I had already implemented my own solution. > > > > I'm not sure I like the magic up-traversal idea at all; even one level up > > things have no relation to where I start and, especially on our servers, up > > is not even an option from the jailed shell. The highest level you'd reach > > would be ~ anyway and the .fabrc solution already handles that. > > > > S > > > > > > > > _______________________________________________ > > Fab-user mailing list > > Fab-user@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/fab-user > > > > > _______________________________________________ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
