[Distutils] [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

[Jeff Rush]

Martin v. Löwis wrote:
> 
> I don't see the need to for PyPI. For packages (or "distributions",
> to avoid confusion with Python packages), I see two options:
> 
> a) provide a single release that supports both 2.x and 3.x.
> b) switch to Python 3 at some point (i.e. burn your bridges).
> 
> You seem to be implying that some projects may release separate
> source distributions. I cannot imagine why somebody would want
> to do that.

Yes, I am assuming that existing projects would at some point introduce a 3.x 
version and maybe continue a 2.x version as separate distros, similar to 
Python itself.  Then the large number of existing unqualified dependencies on, 
say SQLObject, would pull in the higher 3.x version and crash.  It's the older 
projects that don't get updated often that are at risk of being destabilized 
by the arrival of 3.x specific code in PyPI.  Are developers for Python 3.x 
encouraged in 3.x guidelines to release 'fat' distributions that combine 2.x 
and 3.x usable versions?

There is also some hassle with 2.x programmers browsing PyPI for useful 
modules to incorporate in their programs, downloading them (w/easy_install so 
they don't see the project website) and getting streams of errors because they 
unknowningly hit a 3.x-specific version.

Perhaps a convention of a keyword or more likely a new trove classifier that 
spells outs 3.x stuff, with indicators on package info pages and query filters 
on PyPI against that?


>> 2. There have been attempts over the years to fix distutils,
>>     with the last one being in 2006 by Anthony Baxter. He
>>     stated that a major hurdle was the strong demand to
>>     respect backward compatibility and he finally gave up.
> 
> Can you kindly refer to some archived discussion for that?

http://mail.python.org/pipermail/python-dev/2006-April/063943.html

   "I started looking at this. The number of complaints I
    got when I started on this that it would break the
    existing distutils based installers totally discouraged
    me. In addition, the existing distutils codebase is ...
    not good.

    It is flatly not possible to "fix" distutils and
    preserve backwards compatibility." -Anthony Baxter


>>     One of the purposes of Python 3.0 was the freedom to
>>     break backward compatibility for the sake of "doing
>>     the right thing".  So is it now permissible to give
>>     distutils a good reworking and stop letting
>>     compatibility issues hold us back?
> 
> I don't know what the proposed changes are, but for some
> changes; in general, I feel that the need for backwards
> compatibility is exaggerated.

A controversial point, I'm afraid.  Perhaps it is time for a parallel rewrite, 
so that those setup.py who import distutils get the old behavior, and those 
who import distutils2 get the new, and we let attrition and the community 
decide which is standard.

-Jeff