2009/7/7 M.-A. Lemburg <m...@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 <ronaldousso...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
