[Distutils] setuptools: Utility of setup() arguments

[Phillip J. Eby]

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.