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

["Martin v. Löwis"]

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

Passive voice is misleading here: encouraged by whom?

*I* encourage people to consider that option, rather than assuming it
couldn't possibly work. Whether it actually works, I don't know.
I hope it would work, and I hope it would not be fat at all.

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

I'm fine with adding more trove classifiers if that solves the problem
(although I still assume the problem doesn't actually exist).

As always, a classifier should not be added until there actually are
two packages that want to use it.

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

Thanks. I still have the same position as I had then - if
distutils is broken, it should be fixed, not ignored.

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

Is there a list of the problems with distutils somewhere?

It always worked fine for me, so I see no reason to fix it in the
first place.

Regards,
Martin