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

[Jeff Rush]

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?
>>
>> http://mail.python.org/pipermail/python-dev/2006-April/063943.html
>>
> 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?

-Jeff