Python in Linux - barrier to Python 3.x

[David Cournapeau]

On Tue, Sep 21, 2010 at 10:23 PM, Diez B. Roggisch <deets at web.de> wrote:
> Ant <antroy at gmail.com> writes:
>
>> Hi all,
>>
>> I've just seen this: http://sheddingbikes.com/posts/1285063820.html
>>
>> Whatever you think of Zed Shaw (author of the Mongrel Ruby server and
>> relatively recent Python convert), he has a very good point in this. I
>> run Fedora 12 on my home computers, and find it far too much hassle to
>> try to get Python 3 installed. Even the 2.x's are behind - IIRC think
>> it currently uses 2.5.
>>
>> So I really think this is a barrier to entry to Python 3 that we could
>> do without - it's the only reason I do all of my Python work in 2.x, I
>> would jump at migrating to Python 3 if it was easily available on
>> Fedora.
>>
>> Is there a solution to this that anyone knows of? Has Zed jumped to
>> conclusions? Have I?
>
> I think he has a very valid point. I've been arguing quite a few times
> here that e.g. the stupid splitting up of python and python-dev packages
> that a great deal of people trip over should go away.

It is not stupid, it makes a lot of sense when you know the
distributions in question. It means you have a consistent behavior
independently of the language. So of course if you don't care about
the rest of the ecosystem, you will think it is useless overhead.

Also, I doubt that the issue is python vs python-dev - of course,
given that the exact issues are not explained, we can only play guess
games.

>
> But usually people here seem to think that other package management
> systems are the way to go, and python itself must integrate with
> them. E.g. providing dependency information compatible to them and their policies.
>
> I think that's bonkers. You can't support every new kid on the block
> claiming to be the shizzle in package management. Or the next distro
> with it's own packaging policies. And of course the overall release
> planning that says "we use that ancient stable version not supported for
> years anymore, because it's true & tested for us".
>
> IMHO the solution to this is the way Apple does it: they have a System
> Python. Don't mess with it. Seriously. Don't.

Apple's python have caused more issues than all distributions
altogether for Numpy and scipy, at least as far as python itself is
concerned. It is very confusing for many end-users.

> So, in summary, I think if anything, Python should liberate itself from
> the reigns of distro package management, and fix whatever issues there
> are with setuptools (or distutils or pip or distribute or whatever the
> cool kids use these days). And then make people use that to work with
> Python-packages, potentially even in individual, isolated VirtualEnvs
> because of package version conflicts.

This kind of thinking mostly shows a poor understanding of complex
deployment scenario. If everybody worked like that, you would quickly
be unable to build anything stable. True, conflicts are sometimes
unavoidable, but if every library keeps changing your only solution is
isolated environments, you quickly have a mess of a system where many
combinations of libraries are not possible.

The fact is that if you need to assemble softwares from many sources,
you need proper engineering. Isolated environments do not help you
much with that. Maybe you should consider that distros have an
experience that  you don't,

cheers,

David