Python in Linux - barrier to Python 3.x

[Diez B. Roggisch]

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.

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.

But you can install as many other Python versions as you want, or even bundle one
with your own app that depends on it.

People object to this usually for two reasons:

 - additional waste of disk-space. Seriously? A thorough visit of
   youporn.com most probably fills your browser cache with more data
   than all possibly python installations ever can.

 - security issues through aged libraries. Certainly a valid point, but
   then this problem is not limited to Python and needs a more universal
   solution: Meta-information gathering about binary versions of
   libraries, and (safe) upgrades for these. Maybe. I haven't given much
   thought to this, but I think it's an OS thing more than a package
   distro thing.

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.

Diez