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.)