[Distutils] python version information in .egg-info directory name

Bob Ippolito bob at redivi.com
Sat Jul 22 00:29:47 CEST 2006

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.


More information about the Distutils-SIG mailing list