On Tue, Dec 22, 2009 at 2:07 AM, David Cournapeau <courn...@gmail.com> wrote: [..] > >> The "metadata", as defined in PEP 314, >> are not thrown away by Distutils, but properly uploaded at PyPI. > > But there is much more than what PEP 314 defines.
Then that's not the metadata as defined in python packaging, but some other information you are talking about. >Think about > everything which is in an egg, for example. How are files locations > are described, how are files outside site-packages described, etc... > As a concrete example, there is not enough metadata in every installer > so that you can convert from one to the other, even though this would > be very useful and definitely possible. > So it is not just metadata at the "input" stage (although there is > certainly a lot of things lost there too), but how they are > represented internally, and how they are represented in the various > installers. This matters a lot for people who extend distutils. I think you are talking about internal representation of elements in an archive built by distutils here, which is different from the metadata that describes the project/release and pushed at PyPI. There's no need to publish and share those extra information unless you want to create some kind of converter. What's important is to clearly define the metadata of a project, as published at PyPI and installed on your system. Not the internal cooking of each installer. PEP 376 as a matter of fact, provides API to read/write the metadata of installed distributions. Now, for extending distutils, that's another problem: we already said that distutils was hard to extend, and we have proposed some changes for this (for example to have a configure/build/install scheme), but this has nothing to do with the published metadata. As a matter of fact, I am working on a configure command for distutils, looking at 4suite's work I've started a prototype here : http://bitbucket.org/tarek/distutils-configure (early stage) you are welcome to join :) > >> >>> - Linked to the above, metadata are not enforced in pypi. This just >>> cannot work. Most other systems in existence enforce strict rules. >> >> I am not sure what you mean by enforcing strict rules. You need to be >> more precise. > > For example, you can upload a distribution which does not even have a > name, or a version, easy_install tries to find tarballs by scrapping > webpages, etc... Two things: 1/ you get warnings if you try to build a distribution with missing metadata and there's now a command in 2.7 called "check" so you can set a strict control on client side 2/ easy_install doesn't "scrap" webpages but uses a protocol implemented by PyPI - see http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api > >> >> What do you want to do ? reject any package that doesn't meet some QA tests ? >> Is PyPI is a community repository, or an entreprise repository ? > > That's common sense to reject packages which do not define a basic set > of metadata, and this has nothing to do with enterprise vs community. > Debian, for example, enforces metadata in its package, and it does not > qualify as enterprise software to me if the term is meant as the > opposite of community. I am even opposing PyPI to debian packages because PyPI allows anyone to upload some python code to share, even if it doesn't have all the required metadata or QA. Installers are not the only PyPI end users right now. IOW, you don't have to be a professional packager to publish and share code at PyPI. That's how I understand its philosophy and I think it goes pretty well with Python's own philosophy. > >> I would have understood this frustration a year ago, but now, that's >> just a free rant/flame :) > > I have tried to explain several times about describing how files are > installed where, and everytime I was shut down (not by you). In > particular, I think I have explained already why I believe PEP 376 > does not solve the issue of interoperation with other installers > because it loses source/target directory information. Are you referring to the install schemes ? these schemes are described in the stdlib itself, but are not as detailed as what you could find in Debian for sure. And these scheme only concerns Python locations, because other locations were a bit out of distutils scope. But some people are working on extending that in PEP 376 so we can point stuff like man pages etc. But distutils will never ever compete with debian's dpkg or fedora's rpm if you need a full blown packaging system for a given platform. Rather, the best thing we can do is to make sure those packagers can easily extract info out of distutils distributions; if you think this can be improved, if you have examples of info loss, as you said that's the perfect thing to throw in the PEP discussions. And if you already did some months ago, I am sorry, I think you will have to do it again because that just means imho that the "distutils community" was not ready to hear it back then. But it grew up a little bit since then so I think it worth a try. Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
