chris at simplistix.co.uk
Wed Mar 26 19:06:29 CET 2008
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 ;-)
Simplistix - Content Management, Zope & Python Consulting
More information about the Distutils-SIG