[Distutils] setuptools in a cross-compilation packaging environment

[Phillip J. Eby]

At 07:42 PM 10/4/2005 -0700, Brian Zhou wrote:
>Hi all,
>
>I am the package maintainer of python and a couple of python packages for
>the nslu2 optware platform, see http://www.nslu2-linux.org and
>http://ipkg.nslu2-linux.org/feeds/unslung/cross/
>
>There were some distutils features I really appreciate:
>
>1) setup.py install --prefix
>This allows us to install into a separate staging area.
>
>2) setup.cfg [build_scripts] executable option
>
>3) setup.cfg [build_ext] include-dirs, library-dirs and rpath options

All of these options should work just fine; if they don't, it's almost 
certainly a setuptools bug and you should report it here.


>The new setuptools is all nice and easy for end user, but as a package
>maintainer, I'd like to have the option of building a binary package without
>all the dependencies.

In the long run, this should be done by packaging the result of bdist_egg, 
and by default doing bdist_rpm will do this now.  In the short term, unless 
you're switching to an all-egg distribution, you'll probably want to use 
legacy/unmanaged mode.


>Is it possible? How about the above distutils
>features, are there any equivalent?

All of the old 'install' options are available, if you use the appropriate 
command line flags.  Try "setup.py install --help" and look for the rather 
long option name about doing legacy "unmanaged" installation.  With that 
option, a "classic" installation will be done, without an egg being 
built.  However, even if you don't specify that option, all of the options 
you listed above should work anyway.

Please note, by the way, that some packages simply *cannot* work using the 
"unmanaged" mode, and never will.  Such packages *must* be installed as 
eggs, period.  Among these are setuptools itself, and any packages that are 
plugins for Trac or Python Paste, or any other extensible system using 
setuptools to manage plugins.

What's more, packages that explicitly use pkg_resources to request their 
dependencies will not recognize unmanaged packages as fulfilling the 
dependency, which means that over time there will be increasing demand for 
packages to be installed as eggs to start with.

The simplest way to deal with this is to install vendor-packaged eggs to 
wherever the distribution normally installs packaged Python packages, and 
install a corresponding '.pth' file that points to the installed egg.  This 
will ensure that the package is available and can be imported as if it were 
installed the old way, so it doesn't break any non-setuptools-based 
packages.  It also does not require pkg_resources or setuptools to be 
installed unless a given package actually uses them.  (If the package 
contains C extensions, the .egg can be expanded as a directory, so that it 
isn't necessary to extract the .so files at runtime.)