Dinu Gherman
2014-04-07 13:50:49 UTC
Hi everybody!
This is my first post here. I'm using fabric together with vagrant and since I have additional files, like the Vagrantfile, provisioning scripts etc. that made me eventually wrap my fabfile into a Python package (egg). So, there I have now a Python script named to call this package functionality, say "test.py", that actually wraps "fab -f fabile.py" with the fabfile sitting inside the package by using subprocess.Popen(cmd, shell=False, ...). I have attached a minimal version, using tasks running with 'local'.
The first observation is that output for commands containing flags like '-l' is wrapped after 80 characters in my terminal although it is actually wider than that:
$ python test.py -l
running: fab -f test.py -l
Test executing fabric tasks wrapped on the command-line vs. programmatically.
Available commands:
date Print the current date.
date_confirmed Also print the current date, but now with some interactiv...
$ fab -f test.py -l
Test executing fabric tasks wrapped on the command-line vs. programmatically.
Available commands:
date Print the current date.
date_confirmed Also print the current date, but now with some interactive confirmation and long docstring.
But funnily, the -d flag works fine (is not wrapped):
$ python test.py -d date_confirmed
running: fab -f test.py -d date_confirmed
Displaying detailed information for task 'date_confirmed':
Also print the current date, but now with some interactive confirmation and long docstring.
Arguments:
Apart from this running tasks worked quite well until I realized issues with fabric functions like fabric.contrib.console.confirm which interact with the user on the command-line. This makes my call to subprocess.Popen block:
$ python test.py date
running: fab -f test.py date
Mo 7 Apr 2014 15:26:17 CEST
[localhost] local: date
Done.
$ python test.py date_confirmed
running: fab -f test.py date_confirmed
^CTraceback (most recent call last):
File "test.py", line 42, in <module>
print(p.stdout.read().strip())
KeyboardInterrupt
I tried then to work around this by calling the fabric tasks programmatically using the "execute" function, which sort of works (here switched on with an --exec option):
$ python test.py --exec date
executing: date
[localhost] local: date
Mo 7 Apr 2014 15:24:34 CEST
$ python test.py --exec date_confirmed
executing: date_confirmed
Really? [y/N] y
[localhost] local: date
Mo 7 Apr 2014 15:24:38 CEST
But then I don't seem to find a way to execute several tasks chained as when given directly on the command-line for "fab", more or less in order not to loose shared data in the fabric environment.
So I wonder: what is the recommended best practice for wrapping fabric inside another tool/package? Or is there a way to make Popen not block on interactive functions like confirm? I have attached a simple script illustrating what I mean (used in the snippets above), running trivial local tasks without chaining.
Thanks in advance,
Dinu
PS: Sorry if this is a FAQ! If so I've managed to not find it.
This is my first post here. I'm using fabric together with vagrant and since I have additional files, like the Vagrantfile, provisioning scripts etc. that made me eventually wrap my fabfile into a Python package (egg). So, there I have now a Python script named to call this package functionality, say "test.py", that actually wraps "fab -f fabile.py" with the fabfile sitting inside the package by using subprocess.Popen(cmd, shell=False, ...). I have attached a minimal version, using tasks running with 'local'.
The first observation is that output for commands containing flags like '-l' is wrapped after 80 characters in my terminal although it is actually wider than that:
$ python test.py -l
running: fab -f test.py -l
Test executing fabric tasks wrapped on the command-line vs. programmatically.
Available commands:
date Print the current date.
date_confirmed Also print the current date, but now with some interactiv...
$ fab -f test.py -l
Test executing fabric tasks wrapped on the command-line vs. programmatically.
Available commands:
date Print the current date.
date_confirmed Also print the current date, but now with some interactive confirmation and long docstring.
But funnily, the -d flag works fine (is not wrapped):
$ python test.py -d date_confirmed
running: fab -f test.py -d date_confirmed
Displaying detailed information for task 'date_confirmed':
Also print the current date, but now with some interactive confirmation and long docstring.
Arguments:
Apart from this running tasks worked quite well until I realized issues with fabric functions like fabric.contrib.console.confirm which interact with the user on the command-line. This makes my call to subprocess.Popen block:
$ python test.py date
running: fab -f test.py date
Mo 7 Apr 2014 15:26:17 CEST
[localhost] local: date
Done.
$ python test.py date_confirmed
running: fab -f test.py date_confirmed
^CTraceback (most recent call last):
File "test.py", line 42, in <module>
print(p.stdout.read().strip())
KeyboardInterrupt
I tried then to work around this by calling the fabric tasks programmatically using the "execute" function, which sort of works (here switched on with an --exec option):
$ python test.py --exec date
executing: date
[localhost] local: date
Mo 7 Apr 2014 15:24:34 CEST
$ python test.py --exec date_confirmed
executing: date_confirmed
Really? [y/N] y
[localhost] local: date
Mo 7 Apr 2014 15:24:38 CEST
But then I don't seem to find a way to execute several tasks chained as when given directly on the command-line for "fab", more or less in order not to loose shared data in the fabric environment.
So I wonder: what is the recommended best practice for wrapping fabric inside another tool/package? Or is there a way to make Popen not block on interactive functions like confirm? I have attached a simple script illustrating what I mean (used in the snippets above), running trivial local tasks without chaining.
Thanks in advance,
Dinu
PS: Sorry if this is a FAQ! If so I've managed to not find it.