Re: [Fab-user] Getting SyntaxError: invalid syntax from fab
Hi Stas, Unfortunately, Fabric is only compatible with Python 2.5 and up (due to using some new Python features in 2.5,) so 2.4 is not supported :( It's possible to get Python 2.5 on CentOS, but it usually involves building from source (though there are some i386 RPMs for 2.5 floating around) so unsure if that's worth it in your case. Best of luck, Jeff On Tue, Feb 9, 2010 at 5:26 PM, Stas Oskin stas.os...@gmail.com wrote: Hi. I'm trying to launch my first examples with Fabric, but getting the following errors: Traceback (most recent call last): File /usr/bin/fab, line 7, in ? sys.exit( File /usr/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/pkg_resources.py, line 277, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File /usr/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/pkg_resources.py, line 2179, in load_entry_point return ep.load() File /usr/lib/python2.4/site-packages/setuptools-0.6c8-py2.4.egg/pkg_resources.py, line 1912, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File /usr/lib/python2.4/site-packages/Fabric-0.9.0-py2.4.egg/fabric/main.py, line 439 finally: ^ SyntaxError: invalid syntax I've installed Fabric via easy_install on CentOS, and using the python version: Python 2.4.3 (#1, Sep 3 2009, 15:37:37) Thanks in advance! ___ 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
[Fab-user] Log integratiing extra commands
Hi, Back to fabric, I rewrote yesterday my perl deployment tool in fabric. So far, I handle the basic use case simple deployment. I have other UC to implement : - backup (quite easy) - complex deployment For complex deployment, i may need to run extra commandes like run some scripts on one or serveral frontal servers or on a given db. I would like to avoid providing a new fabfile and was looking for taking into account some extra commands which would not be used for simple deployment. Any clue ? My other concern is that I would like that all actions are written to a log file so that I can audit if a deployment went well or not. Deployment on preprod/prod are not made by me but by the firm which manages our servers. So far I have the feeling that logging facilities are limited to stderr/stdout in the current console. Any way to generate a log file that contains all info that are displayed to the users in the console ? I would like both logging and displaying at the same time. Thanks, Nicolas -- Nicolas Steinmetz http://www.steinmetz.fr - http://nicolas.steinmetz.fr/ ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
Re: [Fab-user] Log integratiing extra commands
Hi Nicolas, On Wed, Feb 10, 2010 at 11:32 AM, Nicolas Steinmetz nsteinm...@gmail.com wrote: For complex deployment, i may need to run extra commandes like run some scripts on one or serveral frontal servers or on a given db. I would like to avoid providing a new fabfile and was looking for taking into account some extra commands which would not be used for simple deployment. Any clue ? Could you provide an example here? I'm afraid I don't quite follow what you're asking :) My other concern is that I would like that all actions are written to a log file so that I can audit if a deployment went well or not. Your assumption that output currently only goes to stdout/stderr, is correct -- however, there are plans to change this. See http://code.fabfile.org/issues/show/57 :) There's also nothing preventing you from logging your own messages using the Python logging module, but that obviously doesn't cover the actual stdout/stderr. However, all calls to run() and sudo() return strings containing stdout, and those strings also have a '.stderr' attribute containing stderr -- so you could still rig something up to log both types of output to a file. Again, however, we have plans to make that a lot easier or automatic, in the future. 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] Log integratiing extra commands
Hi, 2010/2/10 Jeff Forcier j...@bitprophet.org Hi Nicolas, On Wed, Feb 10, 2010 at 11:32 AM, Nicolas Steinmetz nsteinm...@gmail.com wrote: For complex deployment, i may need to run extra commandes like run some scripts on one or serveral frontal servers or on a given db. I would like to avoid providing a new fabfile and was looking for taking into account some extra commands which would not be used for simple deployment. Any clue ? Could you provide an example here? I'm afraid I don't quite follow what you're asking :) Yep, of course :-) For now, I have a commands.upd file which can contains commands to execute against some servers : Ex : remote front cd /var/www/myapp php path/to/script.php -s arg : will execute the given command on all frontals remote once front cd /var/www/myapp php /path/to/script2.php -s arg -u arg : will execute the command on the first frontal only remote db mysql -uusser -ppass -e SQL Query : will execute the query on all db servers So my perl script actually : * first push files on given servers (db or frontal according to a tree structure of the package) * execute content from the commands.upd file Most of the time, I do always the same thing in my commands.upd file : clear cache and update version in DB. But sometimes, I can have extra commands to pass (for ex, when I deploy a new town in my app, I have some jobs to run for initialising the meteo block or stations list or ... This scripts are part of my app but I need to call them. So I used to have so far most of the time the same commands.upd file that I extend for a given release with some required commands. I would like to do the same without modifying the fabfile.py (to avoid that at next release there are some old scripts that would be run because they were forgotten). Is it clear enough ? My other concern is that I would like that all actions are written to a log file so that I can audit if a deployment went well or not. Your assumption that output currently only goes to stdout/stderr, is correct -- however, there are plans to change this. See http://code.fabfile.org/issues/show/57 :) There's also nothing preventing you from logging your own messages using the Python logging module, but that obviously doesn't cover the actual stdout/stderr. However, all calls to run() and sudo() return strings containing stdout, and those strings also have a '.stderr' attribute containing stderr -- so you could still rig something up to log both types of output to a file. Again, however, we have plans to make that a lot easier or automatic, in the future. Ok, thanks for the information - Will try to see what can I do with the current .stderr, before 1.0 lands. Nicolas -- Nicolas Steinmetz http://www.steinmetz.fr - http://nicolas.steinmetz.fr/ ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
Re: [Fab-user] Log integratiing extra commands
On Wed, Feb 10, 2010 at 11:54 PM, Nicolas Steinmetz nsteinm...@gmail.com wrote: Hi, 2010/2/10 Jeff Forcier j...@bitprophet.org Could you provide an example here? I'm afraid I don't quite follow what you're asking :) Yep, of course :-) For now, I have a commands.upd file which can contains commands to execute against some servers : Ex : remote front cd /var/www/myapp php path/to/script.php -s arg : will execute the given command on all frontals remote once front cd /var/www/myapp php /path/to/script2.php -s arg -u arg : will execute the command on the first frontal only remote db mysql -uusser -ppass -e SQL Query : will execute the query on all db servers So my perl script actually : * first push files on given servers (db or frontal according to a tree structure of the package) * execute content from the commands.upd file Most of the time, I do always the same thing in my commands.upd file : clear cache and update version in DB. But sometimes, I can have extra commands to pass (for ex, when I deploy a new town in my app, I have some jobs to run for initialising the meteo block or stations list or ... This scripts are part of my app but I need to call them. So I used to have so far most of the time the same commands.upd file that I extend for a given release with some required commands. I would like to do the same without modifying the fabfile.py (to avoid that at next release there are some old scripts that would be run because they were forgotten). Is it clear enough ? Something like that (different commands may execute on different servers with few fab commands), i'm make. For example. Input data: users, groups from several servers (20-30 or more). Some users can be on one or few servers. Need: after inspecting users, i have list (exported to file of course :)) with hosts, users and needed actions (for users for example: block, disable password, change password (password length can be different), create sudo %rule for some group (or for group of some user), add user(s) to group, etc). After that, when i'm execute fab with special command(s), this file loaded, parsed and use env.roledefs, and other combination inspect module, globals() and other, run specified actions (with needed parameters) only on needed hosts. In other varian, i'm make fabfile for deploying oracle ias applications. Several applications on production and testing servers with one fabfile and few commands. But all settings (paths, servers, applications names) for this applications (testing and production) change not very often, and so all this settings i'm write in few python dictionaries. and after run (for example) fab beta deploy, i'm пуt deployed application on testing environment beta (but fabfile, and other included modules, don't contain function beta in this case :)). and if i need new testing environment (gamma), i'm just add new parameters to dictionary, and i can run deploy command fab gamma deploy. in internals, on loading fabfile, i'm analysing fab command line parameters (and change it), based on this command-line parameters and parameters for environments, i'm generating need small functions (that contains atomic functions with passed parameters), and export generated functions to global. and fab can run this on-fly generated functions. Again, however, we have plans to make that a lot easier or automatic, in the future. Ok, thanks for the information - Will try to see what can I do with the current .stderr, before 1.0 lands. Nicolas i'm also try solve this problem with logging. for now, i'm sometimes use decorated fabric functions (run, sudo, and so on). decorator just turn off all function output and redirect stdout with stderr to logging module. and this decorated functions use in fabfile. -- WBW, Unatine mailto:unat...@gmail.com xmpp:unat...@unatine.ru ___ Fab-user mailing list Fab-user@nongnu.org http://lists.nongnu.org/mailman/listinfo/fab-user
Re: [Fab-user] how to hide a method that's not a command, and how to alias a command
Hi Phlip,
On Wed, Feb 10, 2010 at 6:16 PM, Phlip phlip2...@gmail.com wrote:
I can prefix them with _, such as def _find_changed_tests(), but if I
forgot the prefix (or if Python handed me some overwhelming reason to
not underbar the non-command method), how can I hide the method? Is
there a code @decorator?
We're working on having a more flexible, alternative opt-in method
of declaring tasks -- see this ticket and its related ticket(s):
http://code.fabfile.org/issues/show/76
So with that implemented you'd be able to explicitly say that
functions X Y and Z are tasks, and everything else is ignored,
underscore or no underscore.
Theoretically, an extension to this might also be able to help out
your other problem...
So how could I call the command '_int', and then rename it so its
command line argument is int?
...by having syntax like e.g. @task('foo'), so that you can forcibly
rename a task despite the wrapped function's actual name. However,
this isn't a guarantee, just an idea.
I personally think that when it comes to wanting to name things that
clash with Python builtins, you're better off finding an alternate
name. Certainly, having an actual Python variable name overwriting a
builtin is bad form regardless of whether or not it's causing problems
in your specific code at present :) and I wouldn't want to add extra
code to core solely to support such practices.
All that said -- having aliases (if not 'renaming') is something I
think would be generally useful, so I expect it will find its way in
eventually.
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
