[Python-Dev] The Breaking of distutils and PyPI for Python 3000?
jeff at taupro.com
Thu Mar 20 05:41:08 CET 2008
Martin v. Löwis wrote:
>> 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?
"... encouraged in __3.x guidelines__ to ...": I presume although I've not
found them yet that there is some kind of document for developers titled
something like, "how to migrate your Python code from 2.x to 3.x". That
document would be a logical place for advice and consideration of the
tradeoffs of jumping to 3.x, maintaining two synced versions using 2to3 or
3to2, and the risks of keeping two independent releases. Identifying best
practices would help them make good choices for the community.
> *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.
So we don't have an actual success story of a dual-version distribution, even
as a prototype, using 2to3 within a distutils package? I would not encourage
a practice without at least one such example.
>>> Can you kindly refer to some archived discussion for that?
> Thanks. I still have the same position as I had then - if
> distutils is broken, it should be fixed, not ignored.
Since the precise API was not documented well and many people began to make
use of ambiguous internal interfaces, such fixes would indeed break them. So
your vote would be to do the right thing, even if it results in some breakage.
I can respect that philosophy.
>> 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?
Unfortunately no. Much of it is anecdotal, much of it occurs on lists outside
the Python community by those attempting to package things. And some of it
are comments by developers who peeked into the distutils source and blanched.
And some of the problems are not bugs, per se, but disagreement on scope of
functionality and a lack of well-known alternatives. So just "fix it if
broken" doesn't work when there is no agreement on how to expand that scope.
I am working on pulling together such a list however, and getting it into the
tracker, so that debate with a record of decisions can occur. I agree that it
is hard to fix problems if no one is _clearly_ reporting them to us. Too much
smoke, not enough light.
> It always worked fine for me, so I see no reason to fix it in the
> first place.
Pardon my lack of knowledge of your background; when you say it always worked
fine for you, are you referring to personal experiences using it to _install_
software or to experiences as a packager in actually distributing complex
collections of modules on different platforms?
More information about the Python-Dev