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