[Catalog-sig] egg_info in PyPI

Tarek Ziadé ziade.tarek at gmail.com
Sat Sep 18 01:04:18 CEST 2010


On Fri, Sep 17, 2010 at 10:02 PM, Jannis Leidel <jannis at leidel.info> wrote:
> On 17.09.2010, at 20:43, Martin v. Löwis wrote:
>
>> Here at the DZUG conference, we are planning to integrate explicit access to setuptools metadata to the package index.
>>
>> The current idea is to store the contents of the egg_info directory,
>> giving remote access to specific files. By default, PyPI will extract,
>> per release, data from the egg that may get uploaded (using the first
>> one if multiple eggs get uploaded). If no egg gets uploaded, a VM
>> based build service will generate it from a source distributions.
>> Tools like setuptools or distribute could also directly upload this
>> information, e.g. as part of the register command.
>>
>> Any opinions?
>
> I'm confused, wouldn't that basically be a slap in the face for the people having worked on PEP345 and distutils2, especially during the Summer of Code?
>
> Also, and I understand enthusiasm tends to build up during conferences, but wouldn't supporting setuptools' egg-info directory again be a step backwards after all those months of discussion about the direction of Python packaging?

Yeah, we worked on a new standard that was accepted - PEP 345

PyPI is currently publishing pep 345 info as a matter of fact - I did
the patch and there's one package that already uses it
http://pypi.python.org/pypi/Distutils2.  (no deps on this one, but
other stuff like links..)

I am about to release the work we did during GSOC in distutils2, a
first beta that includes all the work we done.

Now you want to publish another metadata format at PyPI ? If PyPI
takes that direction and adopts, promotes and publishes a standard
that is not the one we worked on in the past year, this will increase
our difficulty to push the new format so its adopted by the tools then
the community.

People will just get confused because they will find two competing
metadata formats  That's exactly the situation where we were at, and
that's exactly where I don't want to go back.

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.

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.

We worked hard to build some standards, but if PyPI doesn't help us
here, everything we did and are doing is useless.

Tarek

-- 
Tarek Ziadé | http://ziade.org


More information about the Catalog-SIG mailing list