[Distutils] python version information in .egg-info directory name
doko at cs.tu-berlin.de
Fri Jul 21 22:46:59 CEST 2006
Phillip J. Eby writes:
> Unfortunately, Debian's policy -- especially the idea of mixing paths for
> multiple Python versions -- doesn't mesh well with reality.
that's a misunderstading, we don't do that. common files are shipped
in one location outside of sys.path and linked to a version specific
location inside sys.path for every python version.
> projects don't always install the same files for a given Python version, or
> the same content in the same files. Setuptools is only a relatively minor
> example of this; other Python projects do far more customization of the
> install process (by Python version and dependencies) than setuptools does
> of its own. Bluntly, mixing Python versions on the same path for
> *installed* packages (whether installed by the distutils or setuptools)
> borders on insanity.
again, they are not mixed. I didn't see that many packages with
different files between Python versions. could you give some examples?
> (More precisely, it sounds like exactly the sort of thing to do if one
> wanted to create all sorts of problems for which one could then claim
> credit for fixing as part of a "quality assurance" effort, constantly
> patching upstream packages to work around the problems, thereby cementing
> in one's own mind the importance of doing QA work to fix those upstream
> authors' shoddy work that fails to live up to your distribution's "quality"
> standards. And yet somehow, nobody will ever seem to notice that it's the
> policy *itself* that's causing the problems, because of *course* those
> upstream developers know *nothing* about quality assurance... sigh. But
> that's a rant for another day.)
I don't see the problem you describe. But anyway, doing QA work in
Debian for python packages (related to the pakage itself) is
- to move around files into FHS conforming locations in the file
system (in contrast to the Windows centric view of many upstream
modules / packages installing a thing in _one_ location) and keep the
package working. FHS is not just a quality standard for Debian.
- remove included third party modules and depend on the modules
instead which are shipped in the distribution (removed three copies
of pytz in the last months). Maybe it's the desire of upstream authors
to provide a complete one-click-setup lacking a decent package
management system for other platforms, but it should be an option,
not the default.
- remove files which do not conform to the Debian Free Software
Guidelines (DFSG), which would disallow the distribution of an
upstream package in Debian.
- Fix window'isms like linking extension modules with libpython,
convert file encodings, etc.
- add exact meta information (dependencies) that allows upgrades, even
partial ones, between distribution releases. It would be nice to use
upstream meta information, without relying on a newly invented
dependency tracking system which doesn't integrate well with
existing packaging systems. I think the PEP trying to get this
information into the meta-data was rejected as over-specified.
- split an upstream package into more than one binary package to avoid
unnecessary installations (i.e. install the python-imaging parts,
which do not depend on X or Sane).
The policy addresses other (Debian related) things like not
introducing new debian package names for new python versions (because
that requires interaction by FTP adminstrators) and avoiding uploads
for every python package when the python version changes and hindering
the release process for the distribution (forcing big-bang updates
between the unstable and the testing release).
So yes, I don't expect upstream authors to know anything about Debian
QA and to adjust the packaging instead as a package maintainer.
Non-Debian specific changes are usually forwarded to the upstream
authors. Upstreams aren't a homogenous group, from some authors I get
immediate feedback if I modify something in the package, others don't
see a a need to fix a "python setup.py clean" removing half of the
distributed files which cannot be regenerated.
More information about the Distutils-SIG