Re: [Fab-user] Fabric execution with Python calls instead of command-line

[Carles Barrobés]

Hi Jeff, Travis. Thanks for your replies.

I was not aware of the documentation for running Fabric as a library.

I have been taking a look at the doc and playing around, and have 
decided to take a different approach for my app. Instead using the 
fabfile as the starting point, I'll create a databade of snippets, each 
of them a piece of Python code that calls fabric (actually calls the 
python interpreter ). Each snippet will be compiled and run as needed 
with a method run_in_fabric that will look like:

from fabric.api import run
from fabric.state import env

def run_in_fabric(script, hosts):
   """
   hosts is a list of tuples (hostname, user, password)
   """
   bin_script = compile(script, '<string>', 'exec')
   for host in hosts:
       env.host_string, env.user, env.password = host
       exec(bin_script)


Since I also wanted to have a fabfile around in order to be able to run 
it from the command line, I will be able to easily generate this file 
from the database, e.g. by checking which snippets to export.

Cheers.
C


Jeff Forcier wrote:
> Hi Carles,
>
> On Tue, Nov 23, 2010 at 4:23 PM, Carles Barrobés i Meix
> <address@hidden> 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
>
>