On Jul 21, 2006, at 3:08 PM, Matthias Klose wrote: > Phillip J. Eby writes: >> I read the entire policy you linked to, and I don't actually see >> many problems. >> >> It seems to me that the single largest problem in that policy is >> that it >> clearly predates the existence of the distutils. It has no >> conception of a >> Python *project* or *distribution*, only modules and packages. It's >> therefore not surprising that it also doesn't encompass such >> issues as >> distribution metadata, package data, namespace packages, and the >> like. It >> also explains why the policy is so out-of-sync with e.g. PyPI. (I >> hesitate >> to see what would happen if somebody tries to package any of my >> Python >> projects such as SymbolType or ProxyTypes for Debian: they all are >> modules >> in the 'peak' package, but each is distributed as a separate >> project!) > > The Python policy is just a sub-part of the Debian Policy [1]; the > Debian Policy predates PyPi. You are missing the existing bits about > i.e. distribution metadata, distributions, etc. > [1] http://www.us.debian.org/doc/debian-policy/ > > I cannot find the term "project" in the distutils documentation. > Any pointers? > > So yes, if peak is a rather complex setup, it might be worthful to > have it as an example for a Debian package and to identify omissions > in Debian packaging practices and distutils/setuptools.
What pje means by "project" is the Distribution class in distutils. Effectively, the group of stuff addressed by a single "setup.py" script is a project. >> IMO, any other >> way of doing it is an accident waiting to happen... or else a "job >> security" bonus for the people who write the tools and fix the >> problems. I >> guess it's always better to look at it from the bright side. ;) > > Well, let's see what will happen and lets count the accidents then ;) > Many problems that PyPI and setuptools try to solve are well addressed > by existing packaging tools for Linux and *BSD distributions. It would > be nice to see setuptools to use this infrastructure where available. > Linux and *BSD distributions do integrate software well, PyPI and > setuptools might do that job better for Python things, but just for > Python things. I'm sure you can improve things from both sides. It doesn't really make any sense for setuptools to use "infrastructure where available" [1]. The metadata it needs must be available with the source code, and it needs to be accessible in a platform agnostic way post-installation. Tools like stdeb are being written so that it's easier to build packages for a given existing infrastructure (inheriting the setuptools metadata "for free"). [1] You could argue that easy_install (and the dependency resolution that happens with the "*_requires" lists) should integrate with existing package installation infrastructure where available, but that's a different discussion entirely. We're talking about assembling packages, not acquisition and installation. -bob _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
