Re: [Fab-user] Fabric parameter to load fabfile.py recursive (up in folders)
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
Re: [Fab-user] Fabric parameter to load fabfile.py recursive (up in folders)
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
Re: [Fab-user] Fabric parameter to load fabfile.py recursive (up in folders)
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 -- 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
