[Distutils] python version information in .egg-info directory name
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
>> to see what would happen if somebody tries to package any of my
>> projects such as SymbolType or ProxyTypes for Debian: they all are
>> in the 'peak' package, but each is distributed as a separate
> The Python policy is just a sub-part of the Debian Policy ; the
> Debian Policy predates PyPi. You are missing the existing bits about
> i.e. distribution metadata, distributions, etc.
>  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" . 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").
 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