Phillip J. Eby wrote:
to download them. Using a requires/provides model for dependency resolution would have required new PyPI infrastructure to be built out,
I find it shocking that PyPI doesn't have either a human or machine readable list of dependencies for each version of each package. I mean really, even as a human, how am I supposed to look at a package and PyPI and figure out what else it needs and if it's going to be compatible with my current set of installed packages?
PyPI and the requires/provides PEPs also appear to carry an implicit assumption that these requires/provides are leveled on project+version, without any distinction by Python version and target platform.
True enough. I guess requirements becomes: - the current python version (although, in the absence of a version-specific package, I'd imagine a non-version-specific package should suffice) - the current architecture (although, in the absence of an architecture-specific package, I'd imagine a architecture-independent package should suffice) Still, I wonder if the strategy should be inverted. What I usually end up doing by hand is: - if the package has extension modules: - if I'm on unix, download the source install, run setup.py install - if I'm on windows, download the python-specific installer. If none is available, bin the package - if the package has no extension modules, download the source install and run setup.py install Of course, there's also a great deal of "wtf version of packagex do I currenlty have installed anyway?!" as well :-(
Setuptools OTOH, assumes that specific dependencies are a property of a *binary* distribution, not a source distribution. (i.e., the PEPs put the dependency info in a source package's PKG-INFO... where it's pretty much useless for any purpose).
Yeah, something like PKG-INFO should appear somewhere standard in whatever ends up in site-packages or similar...
I've previously posted some of these comments about the requires/provides PEPs on Python-Dev, Distutils-SIG, and Catalog-SIG, with no response from anyone.
You're making the fatal assumption that people who have views about these things appear on these SIGs :-( I've cared for many years but only found out about the distutils-sig relatively recently. Dunno what catalog-sig is and I don't think I belong anywhere near python-dev ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk