setuptools: Utility of setup() arguments
I'm wondering, is there any reason to use the keyword arguments to setup() that write files to the .egg-info directory, instead of writing those files myself (assuming I was going to hardcode them in the Python source anyway). Specifically I'm coming back to some deployment stuff, and I'd like to make an installation process that installs all the dependencies using --multi-version, and then makes the deployed application require those exact versions -- this way nothing else on the machine should be effected by the installation. Doing this in an automated way seems reasonably straight-forward; read the requires.txt file, figure out what the versions are we installed just now (which might have build tags), and rewrite that file. I can rewrite that file easily, not so easy to rewrite setup.py. Relatedly, I'd prefer having entry_points.txt in my repository, since it's annoying when I forget to update it, or when I run "sudo python setup.py develop" it'll be written out as root, and I'll have to fix the permissions before rerunning "setup.py egg_info". Frankly I'd rather have PKG-INFO in the repository as a text file too, though it concerns me more that it is formed from several keyword arguments instead of one. So, to the degree this works (and I haven't tried it with PKG-INFO), is there any reason to use setup() arguments over editing the files it generates directly? -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
At 05:21 PM 9/6/2005 -0500, Ian Bicking wrote:
Specifically I'm coming back to some deployment stuff, and I'd like to make an installation process that installs all the dependencies using --multi-version, and then makes the deployed application require those exact versions -- this way nothing else on the machine should be effected by the installation. Doing this in an automated way seems reasonably straight-forward; read the requires.txt file, figure out what the versions are we installed just now (which might have build tags), and rewrite that file. I can rewrite that file easily, not so easy to rewrite setup.py. Relatedly, I'd prefer having entry_points.txt in my repository, since it's annoying when I forget to update it, or when I run "sudo python setup.py develop" it'll be written out as root, and I'll have to fix the permissions before rerunning "setup.py egg_info".
Frankly I'd rather have PKG-INFO in the repository as a text file too, though it concerns me more that it is formed from several keyword arguments instead of one.
So, to the degree this works (and I haven't tried it with PKG-INFO), is there any reason to use setup() arguments over editing the files it generates directly?
Only that I personally found editing the files directly to be an enormous pain. :) There are numerous ways to solve your problem, however. For example, you can create a command that runs egg_info and then rewrites the requires.txt file, and run it before commands that need egg_info. For example, you could create an alias like: develop = egg_info strict_requires develop that runs your "exact_requires" to rewrite the file before running develop. Or, you can use a function when passing install_requires: setup( ... install_requires = maybe_exact("Req1", "Req2", ...) ) And have the "maybe_exact" function figure out if it needs to add exact version data to the requirements, perhaps reading from another configuration file. I'm pretty sure that these are just two of the more obvious ways to do it; there are bound to be others. Which way works best depends somewhat on your scenario for how you'd like to activate or deactivate the feature.
Phillip J. Eby wrote:
Only that I personally found editing the files directly to be an enormous pain. :)
Why? The only issue I see is that setup.py puts all that data in one place, where otherwise it's several separate files to work with. But anyway, I guess I'm thinking about tools to make that manipulation easier or more consistent, so I'm apt to consider them separately.
There are numerous ways to solve your problem, however. For example, you can create a command that runs egg_info and then rewrites the requires.txt file, and run it before commands that need egg_info. For example, you could create an alias like:
develop = egg_info strict_requires develop
that runs your "exact_requires" to rewrite the file before running develop.
I think I'd probably want something like: strict_install = egg_info --tag-date strict_requires install I feel like using a specific set of requirements means that the package itself is a new version, hence --tag-date. And the whole thing is best done as an entirely new command (strict_install) since this is something I'd only do for some installations (not during development, for instance), and I don't really want to override an existing command. I'm a little wary of rewriting something that egg_info writes, because egg_info can rewrite it later. But I suppose the command alias makes it into a single operation, so it doesn't seem as fragile. Though one advantage of editing the files is that I could apply strict_requires to a tag and commit those changes, encapsulating the exact environment that was used when creating that tag. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
At 05:59 PM 9/6/2005 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
Only that I personally found editing the files directly to be an enormous pain. :)
Why?
Because I have to create a new file. And if it's a new project, a directory to go with it. Adding arguments to setup() is much easier. Also, setup() arguments are somewhat easier to document.
I'm a little wary of rewriting something that egg_info writes, because egg_info can rewrite it later. But I suppose the command alias makes it into a single operation, so it doesn't seem as fragile. Though one advantage of editing the files is that I could apply strict_requires to a tag and commit those changes, encapsulating the exact environment that was used when creating that tag.
If your command or commands use a configuration file, or store the info in setup.cfg, you can still do that.
participants (2)
-
Ian Bicking -
Phillip J. Eby