Hi All, Apologies if these questions have been answered elsewhere, if they have, please point me at the answers. I've been trying to follow the discussion but the shear volume has overwhelmed me... 1. Is there a canonical way to tell what version a python package thinks it is? 2. Does the python package index contain dependency information? If not, why not? ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Fri, Mar 21, 2008 at 3:57 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Apologies if these questions have been answered elsewhere, if they have, please point me at the answers. I've been trying to follow the discussion but the shear volume has overwhelmed me...
1. Is there a canonical way to tell what version a python package thinks it is?
Not in practice.
2. Does the python package index contain dependency information? If not, why not? ;-)
Not really. I am far from the authority on these topics, but my understanding as a user is that PEPs 241,314,345 attempt to address these issues but are not used in practice. I do not know how to query an installed package to determine its version in canonical way (lot's of projects use __version__, but it isn't required and isn't guaranteed to agree with what distutils thinks is the package version number -- perhaps even worse you have to import the module to get at it). While projects could provide (python package) dependency information with PEP 314, I don't know which ones do, if any. All of this could be from a lack of education on my part, but my guess is that if it were widely used and available it wouldn't be such an issue and I would know more about it since I tend to read the "official" tutorials and manuals.
Alexander Michael wrote:
I am far from the authority on these topics, but my understanding as a user is that PEPs 241,314,345
So PEP 345 is implemented in Python 2.5?
attempt to address these issues but are not used in practice.
How come? Does distutils in 2.5 or setuptools not generate the required PKG-INFO? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Tue, Mar 25, 2008 at 10:14 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Alexander Michael wrote:
I am far from the authority on these topics, but my understanding as a user is that PEPs 241,314,345
So PEP 345 is implemented in Python 2.5?
Yes.
attempt to address these issues but are not used in practice.
How come? Does distutils in 2.5 or setuptools not generate the required PKG-INFO?
IIUC, as far as distutils goes, the metadata shows-up in the sdist, but not in site-packages, so it isn't really useful for introspecting an installation. The ability to specify requirements is virtually undocumented and isn't used in practice to my knowledge. Setuptools makes both pieces of information introspectable for packages it installs (but provides its own way of specifying requirements).
At 10:54 AM 3/25/2008 -0400, Alexander Michael wrote:
On Tue, Mar 25, 2008 at 10:14 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Alexander Michael wrote:
I am far from the authority on these topics, but my understanding as a user is that PEPs 241,314,345
So PEP 345 is implemented in Python 2.5?
Yes.
attempt to address these issues but are not used in practice.
How come? Does distutils in 2.5 or setuptools not generate the required PKG-INFO?
IIUC, as far as distutils goes, the metadata shows-up in the sdist, but not in site-packages, so it isn't really useful for introspecting an installation. The ability to specify requirements is virtually undocumented and isn't used in practice to my knowledge. Setuptools makes both pieces of information introspectable for packages it installs (but provides its own way of specifying requirements).
In fact, setuptools' requirements info is 100% separate from the PEP-specified requirements info. Setuptools allows different requirements for tests, for running the setup script, and for optional add-ons to a project. These requirements also use a different version parsing mechanism etc. One reason for this is that Python 2.3 doesn't support this version stuff, and setuptools was written for 2.3 initially. Another is that the PEP-defined requires/provides data does not allow dependencies to be satisfied merely by looking at target filenames -- i.e., without needing to download them. Using a requires/provides model for dependency resolution would have required new PyPI infrastructure to be built out, whereas a filename-based approach could run on anything. 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. 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). 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.
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
participants (3)
-
Alexander Michael -
Chris Withers -
Phillip J. Eby