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

"Martin v. Löwis" martin at v.loewis.de
Wed Mar 19 14:34:17 CET 2008

> 1. What is the plan for PyPI when Python 3.0 comes out and
>     dependencies start getting satisfied from distribution
>     across the great divide, e.g. a 3.0-specific package
>     pulls from PyPI a 2.x-specific package to meet some
>     need?  Are there plans to fork PyPI, apply special
>     tags to uploads or what?

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.
    The precise strategy to do so might vary. If one is going
    for a single source version, have setup.py run 2to3
    (or perhaps 3to2). For dual-source packages, have setup.py
    just install the one for the right version; setup.py itself
    needs to be written so it runs on both versions (which is
    easy to do).
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.

> 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?

>     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.


More information about the Python-Dev mailing list