Python in Linux - barrier to Python 3.x

[Lawrence D'Oliveiro]

In message

Still, no Python 3 unless I upgrade to Fedora 13, and upgrading
an OS in order to get the latest version of one package is a bit much!

You’re using Fedora, a distro that pretty much demands you upgrade at least
every 12 months, and you’re complaining about it?

 

[Lawrence D'Oliveiro]

Of course, in a ideal world, distutils would hook into the distros
dependency system + simply say "please install python-dev first".

But I'm not convinced that putting the weight here on the shoulders of
the python-communtiy to deal with arbirtray decisions of the dozen or
how many distros + packaging schemes out there is possible - and helpful.

Fair enough. I think the right answer is for the package-management systems
to bear the burden of coping with the established installation mechanisms of
particular major subsystems.

There may be a slight mismatch, in that distutils is source-based, whereas
most Linux distros (with the notable exception of Gentoo) expect to
distribute and install prebuilt binaries. I suspect this is not
insurmountable.

 

[Lawrence D'Oliveiro]

comp.lang.python doesn't handle Linux packaging [issues] ...

Why not? We regularly seem to was^H^H^Hspend a lot of time with Windows-
specific packaging problems, installation problems and configuration
problems, why not Linux ones as well?

 

[Steven D'Aprano]

In message


You’re using Fedora, a distro that pretty much demands you upgrade at
least every 12 months, and you’re complaining about it?

"Demands"?

I'm using Fedora 7. Obviously the demands have been going to my old
address.

 

[Steven D'Aprano]

Yes you are right - I've checked on my home machine, and it is indeed
2.6. Still, no Python 3 unless I upgrade to Fedora 13, and upgrading an
OS in order to get the latest version of one package is a bit much!

Or you could install from source, which takes all of three minutes of
effort. Well, maybe four. Eight if you've never done it before. Maybe
twelve if you're cautious.

Here's a link to get you started:

http://www.python.org/download/releases/3.1.2/

The only gotchas you're likely to run into are, you need root, or at
least sudo (which you would need for an rpm installation as well), and
don't forget to run `make altinstall` instead of `make install`. Read the
README for details.

You might have a policy of never installing anything that doesn't go
through the system packaging system, and that's a perfectly good policy.
But that's not Python's responsibility. Go nag the Fedora folks. Or ask
around, somebody surely has built an rpm for Python 3.1.

I know that this is a distribution issue, and not strictly a Python
one,

It's not a Python issue *at all*.

but the issue exists primarily because python is such a
successful language it has become deeply embedded in linux
distributions, and so there is now a lot of work involved in checking
that a python upgrade doesn't break things.

Well, maybe so, but that has nothing to do with the availability of one
or more non-system Pythons. My sys admin foo is mediocre at best, but
I've had no problems at all with installing Pythons 1.5 through 3.2
inclusive on my system, while leaving 2.5 as the system Python. In my
experience installing from source on Fedora systems Just Works.

 

[David Cournapeau]

Or you could install from source, which takes all of three minutes of
effort. Well, maybe four. Eight if you've never done it before. Maybe
twelve if you're cautious.

That only works if some cases. If you need some additional packages,
especially ones which depend on C extensions, that may be difficult or
even hopelessly intractable. Typically, if your want to install say
matplotlib with pygtk with a custom built python, you are in for a fun
ride because you have to rebuild everything. That the cases where you
really want something that integrates well with the native packaging
system, whatever that ends up to be.

cheers,

David

 

[Steven D'Aprano]

That only works if some cases. If you need some additional packages,
especially ones which depend on C extensions, that may be difficult or
even hopelessly intractable.

First of all, the issue being raised was Python itself, not third party
packages. Just because my distro supports Python 3.1 doesn't mean it
supports Some_Random_Package-0.2.1 too.

And secondly, if it's hopelessly intractable to install a package from
source, it will be hopelessly intractable for your distro packagers to
build a package for it too. The difference is that if it's merely
inhumanly difficult, the packagers can do it *once*, instead of expecting
everyone to do so.

Typically, if your want to install say
matplotlib with pygtk with a custom built python, you are in for a fun
ride because you have to rebuild everything.

That's not what I consider a typical case. But I take your point.

That the cases where you
really want something that integrates well with the native packaging
system, whatever that ends up to be.

Oh of course. That's the ideal situation. But just because something
falls short of the ideal doesn't mean you can't still get it. If you want
Python 3.1 and your distro doesn't support it, you don't *have* to change
distros.

 

[David Cournapeau]

That's not what I consider a typical case. But I take your point.

It is an acute problem in the numpy/scipy community, and I think it
generalizes to any community which depends quite a bit on C
extensions. I am convinced that the only solution that can work in
those cases is *more* integration with native solutions, not less.

That's why I worry when people suggest to *only* focus on making
python-only solutions. Of course, python-specific solutions are fine
as long as they don't make it more difficult to support the
native-integration goal (which sadly has been the trend up to now).

cheers,

David

 

[Lie Ryan]

comp.lang.python frequently deals with problems caused by this and other
distro-related issues. Your are welcome to not participate on these
discussions.

The state of affairs isn't ideal, and there is improvement options on
all sides. I'm just astonished that people seem to think that distros in
general are better and should be left alone, than what a more python
centric solution could be.

If your distro's package management system doesn't provide you with the
packages you need, then you have made the wrong choice of distro; it's
neither the fault of the distro, package manager, or python; the
distro's policies just does not suit your needs, and either you have
made the mistake of choosing that distro or the other distros are even
worse. Maybe it's time to evaluate whether staying in your current
distro is still beneficial, or it's more hassle than its worth, or if
you want to fix the distro's package manager in some way.



Package Management Triangle

reliability
/ \
/ Pick \
/ any \
/ two \
simplicity ------------ configurability


Ubuntu's (and I believe Debian's) apt-get and Add/Remove Program is very
easy to use and stable, but there is not much configurability, you get
what your package manager gives you. Gentoo's Portage is extremely
configurable, it almost always gives you the latest versions and almost
all of the valid configurations allowed by upstream developer, but the
system is nowhere near simple, and every system you build using Portage
is basically untested system.