[Python-Dev] The Breaking of distutils and PyPI for Python 3000?
"Martin v. Löwis"
martin at v.loewis.de
Thu Mar 20 02:25:40 CET 2008
> 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
More information about the Python-Dev
mailing list