[Catalog-sig] egg_info in PyPI
sridharr at activestate.com
Sat Sep 18 02:23:01 CEST 2010
On 2010-09-17, at 4:04 PM, Tarek Ziadé wrote:
> I am not even understanding what's the benefit of doing this since an
> egg_info directory is obtained at *build* time and can differ from a
> machine to another, so it seems pretty useless for me to publish this.
I am in full agreement with Tarek here. At ActiveState, we maintain our own index that differs from PyPI in two ways (among others):
- use setuptools.package_index to scrap sdists for packages that don't upload them to pypi
- PKG-INFO and requires.txt are extracted (if doesn't exist, generate using egg_info cmd) from each of the sdist
(and then our index provides the full metadata - with internal links to sdists - as a sqlite db for the builder processes on each platform)
The problem with extracting PKG-INFO and requires.txt on the index server is that, the contents of requires.txt sometimes differ based on which platform and Python version on which the egg_info command was run. For eg., the "tox" project depends on "virtualenv" package if it is run using Python2, but not on Python3.
> The whole point of PEP 345 is to extend our metadata to statically
> provide dependencies at PyPI, thanks to a micro-language that allows
> you to describe dependencies for any platform.
Static metadata would allow packages like "tox" to configure Python version / platform specific dependencies without resorting to runtime checks.
> We worked hard to build some standards, but if PyPI doesn't help us
> here, everything we did and are doing is useless.
Ideally, in future - I should be able to query static metadata (with environment markers and such) for *any* package from PyPI. And this static metadata is simply a DIST-INFO file (instead of being a directory with a bunch of files in it). I don't really see a point in providing access to, say, the list of entry points of each package. As for as package managers is concerned, the only things that matter are a) list of package names and versions, b) source tarball for each release c) and the corresponding metadata with dependency information.
More information about the Catalog-SIG