[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