[Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata

[Paul Moore]

2009/7/7 M.-A. Lemburg <mal at egenix.com>:
> The PEP should take the chance to define not only the
> directory, but also the complete set of files in there and
> their format.
>
> A typical setuptools dir looks like this:
>
> dependency_links.txt
> namespace_packages.txt
> not-zip-safe
> PKG-INFO
> requires.txt
> SOURCES.txt
> top_level.txt
>
> Ie. a complete mess of upper-case/lower-case names, names with
> underscores or hyphens as word separator, files with extensions,
> files without them.
>
> This needs some serious cleanup.
>
> A new dir name will allow to do this, so +1 on a new dir name.

I agree the current situation is a mess. I believe that everything you
mention is related to setuptools - so essentially, we have the
situation:

- the existing setuptools format is a mess (at least in the opinion of
MAL and me :-))
- PEP 376 is an opportunity to consider cleanup
- there are some strong supporters of keeping things setuptools-compatible
- nobody has come forward with any other real-world use case than setuptools
- consequently, those of us arguing for cleanup are talking theoretically :-(
- Do you (MAL) have any real use for this data? Any non-setuptools use
case, no matter how small, would really help here.

I suspect practicality will beat purity here. Which would be fine, if
the "practical" cases weren't just setuptools.

I understood that there was a lot of interest in a "distutils cleanup"
from the packaging community. And yet so far in this discussion, the
main participants have seemed to be (apologies to anyone if I've
misunderstood their position):

- Tarek, trying to get the proposal he thrashed out in the distutils SIG agreed
- Me, advocating Windows issues and PEP 302 integration (to cover eggs
and general flexibility)
- Phillip (and occasional others), representing setuptools POV
- Interested python-dev participants

Nobody representing any other 3rd party packaging solution than setuptools.

Much as I'd like to, I can't really argue the case for breaking
setuptools compatibility without practical reasons. And if we're not
going to do that, PEP 376 reduces to a further stage of the
incremental move of setuptools into distutils core (by removing the
partial solution of a .egg-info file, and replacing it with a full
setuptools .egg-info directory, plus a few introspection APIs as a
sweetener).

2009/7/7 Ronald Oussoren <ronaldoussoren at mac.com>:
> But why break existing code without having any other benifits?  If I read
> the discussion correctly the name would be changed without any changes to
> the contents of the metadata directory.  I would be more inclined to be in
> favour if the name change had a sound technical reason, such as a change of
> the contents of the directory which would make setuptools "egg-info"
> directories incompatible with the PEP376 ones.

See MAL's comments above, and my response. If (and only if!) his
proposal is accepted, then a name change starts to be worth discussing
further. As things stand at the moment, the structure appears to be
setuptools-compatibile (other than the new RECORD file, which Phillip
has committed to adding) so a name change isn't worth it.

I can't comment myself on setuptools compatibility, so I'm assuming
here that Phillip will speak up if the proposed format is *not*
compatible...

Paul.