[Twisted-Python] sub options in twisted applications
I don't know if this is useful/safe, but I have written a patch that allow users to pass additional command line arguments to an application started with twistd -y. I don't know if this is compatible with mktap, this is why I have posted the "patch" here and not on the traker. ########## In twisted.scripts.twistd def runApp(config): import sys sys.argv = appArgv ... def configHelper(argv): idx = 1 for i, opt in enumerate(argv[1:]): if not opt.startswith('-'): idx = i + 1 break tmp = argv[idx:] if len(argv) > idx: del argv[idx + 1:] return tmp appArgv = [] def run(): global appArgv import sys appArgv = configHelper(sys.argv) app.run(runApp, ServerOptions) ######### Now if I do twistd -y myapp -x -y sys.argv is ["myapp", "-x", "-y"] Regards Manlio Perillo
On Sun, 11 Jun 2006 07:48:51 -0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
I don't think this is a good idea. As JP said, .tac files *are* configuration, they don't *take* configuration. If you want to write some patches that improve the ability to write command-line tools that take arguments, submit a patch that fixes this: http://twistedmatrix.com/trac/ticket/1501 :)
On Sun, 2006-06-11 at 07:33 -0400, glyph@divmod.com wrote:
Or http://twistedmatrix.com/trac/ticket/1490 -- Itamar Shtull-Trauring http://itamarst.org
Jean-Paul Calderone ha scritto:
In general software (but I have only Windows experience here) all modules are in the same directory. So when I run the "main" module, the software directory is in PYTHONPATH. But what if I want to put pyapp.tac in /etc/myapp/ while the application is in /usr/lib/myapp? Thanks and regards Manlio Perillo
On Mon, 12 Jun 2006 15:52:22 -0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
If there were actually a valid reason to do this, your init script would do something like ... PYTHONPATH=/usr/lib/myapp:$PYTHONPATH twistd -y /etc/myapp/myapp.tac ... but there isn't. Why is your application so special that it can't be installed in the same place as every other python application? Why shouldn't the regular Python interpreter be able to 'import' your modules? (If the user wants to put your module somewhere other than site-packages that is certainly their choice, but that is what sitecustomize and PYTHONPATH are for.) Does anyone else remember commercial UNIX applications that would require installation to a fixed, non-standard location and then require that you set LD_LIBRARY_PATH in some configuration file? That was gross, and lead to all manner of problems, this is no better.
On Tue, 13 Jun 2006 06:52:16 -0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
glyph@divmod.com ha scritto:
This is really a configuration decision that gets mixed up with an application's packaging. Some GNOME applications do live in site-packages by default; for example, gnome-blog. Some, like Quod Libet, are only in their own installation directory because they don't use their own namespace (and this is arguably a bug). Some, like Straw, have no real reason. Mailman puts itself into a non-site-packages directory because it wants to be able to install its own versions of the 'email' and 'codecs' packages, regardless of what other versions of those bits of software you have on your system. Although I'm not a huge fan of the "egg" format as it stands, it does solve the particular problem of per-application version dependencies a bit better than these ad-hoc decisions made on behalf of each application in a platform-specific way. On a platform like Debian where the package manager is verifying that your package versions match, the additional support is unnecessary unless you have applications which explicitly depend on different, incompatible versions of the same library. In short: your application should at least be *able* to install itself in site-packages on systems where the package versions line up properly. In the case where they don't, setting PYTHONPATH in a startup script is perfectly acceptable. None of this, you'll notice, has anything to do with .tac files :). If your application requires a particular version of Twisted, for example, the 'twistd' script which your startup script invokes will need to be specifically selected as well; you can't run whatever random twistd is on your PATH and then require a specific version of twistd in the .tac, so it's too late to start manipulating your sys.path there.
On Sun, 11 Jun 2006 07:48:51 -0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
I don't think this is a good idea. As JP said, .tac files *are* configuration, they don't *take* configuration. If you want to write some patches that improve the ability to write command-line tools that take arguments, submit a patch that fixes this: http://twistedmatrix.com/trac/ticket/1501 :)
On Sun, 2006-06-11 at 07:33 -0400, glyph@divmod.com wrote:
Or http://twistedmatrix.com/trac/ticket/1490 -- Itamar Shtull-Trauring http://itamarst.org
Jean-Paul Calderone ha scritto:
In general software (but I have only Windows experience here) all modules are in the same directory. So when I run the "main" module, the software directory is in PYTHONPATH. But what if I want to put pyapp.tac in /etc/myapp/ while the application is in /usr/lib/myapp? Thanks and regards Manlio Perillo
On Mon, 12 Jun 2006 15:52:22 -0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
If there were actually a valid reason to do this, your init script would do something like ... PYTHONPATH=/usr/lib/myapp:$PYTHONPATH twistd -y /etc/myapp/myapp.tac ... but there isn't. Why is your application so special that it can't be installed in the same place as every other python application? Why shouldn't the regular Python interpreter be able to 'import' your modules? (If the user wants to put your module somewhere other than site-packages that is certainly their choice, but that is what sitecustomize and PYTHONPATH are for.) Does anyone else remember commercial UNIX applications that would require installation to a fixed, non-standard location and then require that you set LD_LIBRARY_PATH in some configuration file? That was gross, and lead to all manner of problems, this is no better.
On Tue, 13 Jun 2006 06:52:16 -0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
glyph@divmod.com ha scritto:
This is really a configuration decision that gets mixed up with an application's packaging. Some GNOME applications do live in site-packages by default; for example, gnome-blog. Some, like Quod Libet, are only in their own installation directory because they don't use their own namespace (and this is arguably a bug). Some, like Straw, have no real reason. Mailman puts itself into a non-site-packages directory because it wants to be able to install its own versions of the 'email' and 'codecs' packages, regardless of what other versions of those bits of software you have on your system. Although I'm not a huge fan of the "egg" format as it stands, it does solve the particular problem of per-application version dependencies a bit better than these ad-hoc decisions made on behalf of each application in a platform-specific way. On a platform like Debian where the package manager is verifying that your package versions match, the additional support is unnecessary unless you have applications which explicitly depend on different, incompatible versions of the same library. In short: your application should at least be *able* to install itself in site-packages on systems where the package versions line up properly. In the case where they don't, setting PYTHONPATH in a startup script is perfectly acceptable. None of this, you'll notice, has anything to do with .tac files :). If your application requires a particular version of Twisted, for example, the 'twistd' script which your startup script invokes will need to be specifically selected as well; you can't run whatever random twistd is on your PATH and then require a specific version of twistd in the .tac, so it's too late to start manipulating your sys.path there.
participants (4)
-
glyph＠divmod.com -
Itamar Shtull-Trauring -
Jean-Paul Calderone -
Manlio Perillo