[Fab-user] Fabric execution with Python calls instead of command-line
Hi all, I'm writing a Django site to allow me remotely manage a series of customer installs of a web application using fabric. My goal is to call fabric from within some of my Django views (i.e. run some task in a fabfile on some remote servers, all from within the webapp), but I wouldn't like to run fab necessarily as a subprocess. I'd like to call the equivalent python methods of fabric instead of a command line. I was taking a look at the sources of the fabric.main module but it seems to rely very much on command line argument parsing but it doesn't seem to provide the necessary high-level functions to separate parsing and execution (main() is 150 lines and does a lot of stuff). So far I started using load_fabfile to load a fabfile and get a list of tasks, so that I can present them in my view for selection. But since the fabric.main module is an undocumented part of fabric, I'm not sure I can rely on it staying stable across releases. My questions, mainly to the developers: - Can I rely on using functions in fabric.main? - Are there plans to refactor fabric.main so that it is more usable in the way I suggest, and eventually become a published API? - Would you be open to contributions in that direction? Thanks in advance. C. ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
Re: [Fab-user] Fabric execution with Python calls instead of command-line
Hi Carles, On Tue, Nov 23, 2010 at 4:23 PM, Carles Barrobés i Meix car...@barrobes.com wrote: - Can I rely on using functions in fabric.main? At this time, no, it's not part of the published API. Basically, if it's not in the API section of the docs, it's not public API material, and we reserve the right to change it in otherwise backwards-compatible releases. Doesn't mean we *will*, but this is the usual caveat emptor with all APIs :) - Are there plans to refactor fabric.main so that it is more usable in the way I suggest, and eventually become a published API? Yes-- in future releases we'll be refactoring more of that stuff out into things such as e.g. execute(task_obj, host_list) and having fabric.main eat that dogfood. Ideally, fabric/main.py will end up being a very light wrapper that just handles CLI options and fabfile discovery and that's it. Not sure when we'll get there but it is definitely planned. - Would you be open to contributions in that direction? We're always open to ideas and patches, though this particular sort of thing (core features) is more sticky than other parts of the codebase and changes to it will probably be met with more skepticism or at least need more time to be mulled over :) Just so you're aware. Finally -- I just added a note on how to use Fabric as a library, to the docs, the other day: http://docs.fabfile.org/usage/library.html By following that, you don't actually need to parse a fabfile at all. Simply importing it as a Python module and calling task functions may suffice, depending on how much main-like stuff (env.hosts, host/role decorators, etc) the fabfile relies upon to work correctly. Most folks tend to use Fabric in an either-or fashion -- writing fabfiles for use with 'fab', OR using Fabric's API solely as a library and disregarding 'fab' entirely -- so if you truly want to do both you may be the first person to have that particular need. It should be possible, but might require some refactoring of your fabfile into something more library-esque, and may also require a bit of tweaking of host lists and such on the non-fabfile side (again as outlined briefly in that library-use doc). Hope that all makes sense, blasting it out as I leave work for the day :) Best, Jeff -- Jeff Forcier Unix sysadmin; Python/Ruby engineer http://bitprophet.org ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
Re: [Fab-user] Fabric execution with Python calls instead of command-line
I'll take a stab at this with caveat that I'm not the maintainer... Ahh - as I was writing this Jeff chimed in. Anything I say here that's in contradiction to him, believe him, not me (though I think we're actually in agreement on the various points). :-) On Tue, Nov 23, 2010 at 3:23 PM, Carles Barrobés i Meix car...@barrobes.com wrote: My questions, mainly to the developers: - Can I rely on using functions in fabric.main? Sort of. The plan is to refactor all that code heavily post 1.0, but as I understand it, the code will stay pretty much as-is (or at least BC) through the various 1.x releases. If anything, you'll have some better options available and those will be the deprecated way of interacting with the code, but they'll be there at least until 2.0. Again though, as is my understanding. That said, you might want to look at my fork of Fabric on GitHub. It does have some pretty heavy refactoring of that code to allow for things like namespace tasks (think `fab db.init`, `fab django.run_tests`, etc.). - Are there plans to refactor fabric.main so that it is more usable in the way I suggest, and eventually become a published API? Yes, yes, and more yes. Ideally we'll have a runner script that pulls the relevant pieces from the command line and then invokes Fabric. There's talk of a three(ish)-step process as well, the first one that loads the minimum amount of Fabric necessary to parse a fabfile, followed by the loading of the fabfile at which point other tasks and plugins and roles and such can be defined and modify things such as the command parameters, and finally the execution of the code. - Would you be open to contributions in that direction? Yup. Right now the big changes coming down the pipe for 1.0 are some get/put finishing touches, followed by (hopefully) all of my namespace task, __all__, etc., changes (my master on GH). After that I believe 1.1 and 1.2 are spoken for, but anything you're interested in doing, go for it. One thing we've (well, I've) definitely learned from though is to make topic branches. I intended my code to be one or two commits, and now am some 30 commits off of being in sync with the main source. A lot of my changes build on other changes, so they're a lot harder to break into branches now. -T ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
