Harry George <[EMAIL PROTECTED]> writes: > Robert Kern <[EMAIL PROTECTED]> writes: > >> Harry George wrote: >> >>> We need to know the dependencies, install them in dependency order, >>> and expect the next package to find them. "configure" does this for >>> hundreds of packages. cmake, scons, and others also tackle this >>> problem. Python's old setup.py seems to be able to do it. >> >> No, generic setup.py scripts don't do anything of that kind. >> > > Ok, setup.py itself may not do the work, but from the end users' > perspective it works that way. Setup.py runs a configure and a make, > which in turn find the right already-installed libraries. The point > is, setup.py plays well in such an environment.
Some setuptools-based packages do that. Some pure-distutils packages do that. Some setuptools-based packages don't do that. Some pure-distutils packages don't do that. Regardless of that logic, it's true that, pragmatically, setuptools' support for dependency resolution encourages an increasing reliance on explicitly-declared dependencies on *Python* projects ("project" here meaning something with a setup.py -- a project may contain several Python packages / modules, and several projects may provide (parts of) a single Python package, as with zope.*). However, pre-setuptools, one rarely saw Python packages being discovered using autotools (configure &c.). *System* features (presence/absence of libraries, &c.) were indeed discovered that way. I don't know of any Python projects that previously used autotools and stopped doing so as part of a switch to setuptools). John -- http://mail.python.org/mailman/listinfo/python-list