[Distutils] EasyInstall and build-time dependencies

[Phillip J. Eby]

At 12:36 PM 6/9/2005 -0700, Ronald Oussoren wrote:
>Are there any plans to teach EasyInstall about build time
>dependencies? And example of this would be the dependency of PIL on
>libjpeg and libtiff.

Yes and no.  I plan to refactor EasyInstall so that packages that want to, 
can use its find-and-download capabilities to install their own 
dependencies of that sort.  However, if PyPI ever includes metadata that 
EasyInstall could consult about a package's non-Python dependencies, it 
could be used to inform the user.

There's also the possibility that we could enhance Eggs to be able to deal 
with headers and libraries, and then create distutils wrappers for building 
libraries or finding them on the system.  Then, PIL could depend on 
"py-libjpeg" and "py-libtiff" wrappers that could be used to find the 
headers and libraries for compiling the PIL extensions.

But, I mainly expect build-time dependencies to have to be handled by the 
to-be-built package, not by EasyInstall directly.  The package with the 
dependencies would use setuptools' new EasyInstall-based commands to locate 
and install the dependencies before building, placing the dependencies' 
eggs in the building package's dist directory, where the parent installer 
will notice and install them along with the building package.

So, in terms of your example, PIL would have to use setuptools in its 
setup.py, and request build-time availability of py-libtiff and 
py-libjpeg.  Setuptools would download them each to emporary build/ 
subdirectorie, and finish by putting py_libtiff-blahblah.egg and 
py_libtiff-blahblah.egg in dist/.  PIL would then build, having found out 
what subdirectories to use as include and library dirs for its build 
process.  You'd then have a PIL .egg in dist/ as well.  The EasyInstall 
that downloaded PIL in the first place would then spot the eggs and install 
them in *its* dist/, or site-packages or --install-dir or whatever the 
final resting place should be.

So how do these hypothetical py_libtiff/py_libjpeg packages work?  Well, 
presumably they're going to be rather platform and even packaging-system 
specific.  For Linux and friends, it'll probably look in the "usual places" 
for these things, or maybe use rpmfind or other packaging system indexes to 
see if it can install what you need that way.  Or maybe it'll build from 
source.  Heck if I know.  :)  That's really designing a whole 'nother level 
of installation system, that I'm not trying to tackle just yet.

Personally, I'd just as soon see package authors and secondary distributors 
just build platform-appropriate .egg files and let people download those, 
rather than trying to solve this.  Relatively few Python packages contain a 
significant number of extensions, and it seems to me that most of them that 
do, don't have any external library dependencies.  The exceptions are 
things like PIL, PyGame, DBAPI modules, and other "interface with some 
other system" modules.

However, typically these are offered as win32.exe's, or .rpms, or whatever 
else.  So packaging as .eggs certainly makes sense there too.