5 ms·

It's not just Java. Python is stuck at 2.4 in most Linux distros, and arguably Python's been a symbiotic part of Linux's success.

RyanMcGreal 16y ago
I don't quite understand this. Can't Python 2.5 and 2.6 run scripts that were written for 2.4?
- FooBarWidget 16y ago
  For the most part yes, but there are minor incompatibilities. New keywords have been introduced, and if you used those keywords as names in your app...
  - RyanMcGreal 16y ago
    Good point. That's what you get for naming your variable "with", I suppose.
dochtman 16y ago
I just don't see this being true. In what distro is it stuck at 2.4?
- jedwhite 16y ago
  http://sheddingbikes.com/posts/1285063820.html http://sheddingbikes.com/posts/1285063820.html
- wazoox 16y ago
  Maybe RedHat, but it's about it. Even Debian Stable comes with 2.5. BTW this rant about impossibility to upgrade is a classic one and nonetheless wrong. You're perfectly able to install new versions of python, or perl or whatever given that you do that in /usr/local to keep the official version alongside the new one. I do this all the time, my system comes with perl 5.10 but I regularly install the newest releases in /usr/local, or even development versions. No problem.
- viraptor 16y ago
  CentOS 5 (even latest 5.5). You can install python25 or even python26, but 2.4 always stays as a default. As long as you know about it, you can fix scripts, but any downloaded program needs a change in shbang line, or at least running explicitly via python-2.X. But yes, "most Linux distros" part is completely untrue. Most have at least 2.5 - or higher.
etal 16y ago
This problem is different from the Python issue Zed Shaw wrote about. In Java, developers will bundle dozens of random .jar files with their application. Other versions of these libraries may exist in a Linux distribution already, but specific Java apps aren't linking to those and carefully documenting how to install all the dependencies (or which ones are optional). Instead, from the distro's point of view, these Java apps are being released with a bunch of binary blobs that may or may not contain bugs that need patching later. Which partly defeats the purpose of package management. Python programmers don't do this. Distros love Python, which is why so many of their system administration/automation scripts depend on it. This puts some tension between packagers, who use it as a bash/perl replacement, and developers like Zed, who want to treat it like an up-to-date library -- but realize that the Java solution of just bundling the whole thing with the main app is ugly. That tension exists because Python developers haven't run amok the way Java developers have.
- regularfry 16y ago
  I'd love to see distros start to introduce (for instance) separate python-sys and python-dev packages. The OS would use python-sys for the admin and automation scripts, but if you wanted to use Python for your own projects, you could use python-dev, which could be a later version. Possibly python-dev could even track upstream more closely. Either way, you'd decouple the system's need for a stable, proven and predictable Python from the user's need for new(er) shiny.
  - etal 16y ago
    If pip/Distribute eventually works as smoothly as apt-get, I'll be a happy guy.
regularfry 16y ago
I've come to the conclusion that every language is broken from the point of view of people actually working with the language rather than relying on tools previously written in it. Ruby has broken out of this with rvm, maven kinda-sorta fixes Java but seems to come with a bundle of baggage, virtualenv with your own python build works well enough. CLBuild and QuickLisp, the Haskell Platform and from what I can tell Racket automate a similar approach. I don't know much about the Perl ecosystem, but at a guess I'd say that Perl's backwards compatibility saves it better than most. And this is before you start looking at the code quality and release processes of the libraries packaged in the languages' own distribution mechanisms. Seriously, unless you're working in C/++, I think it's only worth using the system-bundled languages if you're actually targeting the OS itself. If you're targeting more than one platform, using your own build seems to be the only way to stay sane. If you're only targeting a single platform, unless you're tracking a bleeding-edge-style distro like Arch, you can guarantee that all the fun development is going to be going on somewhere you can't reach. Luckily, we have checkinstall.

RyanMcGreal 16y ago

I don't quite understand this. Can't Python 2.5 and 2.6 run scripts that were written for 2.4?

FooBarWidget 16y ago
For the most part yes, but there are minor incompatibilities. New keywords have been introduced, and if you used those keywords as names in your app...
- RyanMcGreal 16y ago
  Good point. That's what you get for naming your variable "with", I suppose.

dochtman 16y ago

I just don't see this being true. In what distro is it stuck at 2.4?

jedwhite 16y ago
http://sheddingbikes.com/posts/1285063820.html http://sheddingbikes.com/posts/1285063820.html
wazoox 16y ago
Maybe RedHat, but it's about it. Even Debian Stable comes with 2.5. BTW this rant about impossibility to upgrade is a classic one and nonetheless wrong. You're perfectly able to install new versions of python, or perl or whatever given that you do that in /usr/local to keep the official version alongside the new one. I do this all the time, my system comes with perl 5.10 but I regularly install the newest releases in /usr/local, or even development versions. No problem.
viraptor 16y ago
CentOS 5 (even latest 5.5). You can install python25 or even python26, but 2.4 always stays as a default. As long as you know about it, you can fix scripts, but any downloaded program needs a change in shbang line, or at least running explicitly via python-2.X. But yes, "most Linux distros" part is completely untrue. Most have at least 2.5 - or higher.

etal 16y ago

This problem is different from the Python issue Zed Shaw wrote about. In Java, developers will bundle dozens of random .jar files with their application. Other versions of these libraries may exist in a Linux distribution already, but specific Java apps aren't linking to those and carefully documenting how to install all the dependencies (or which ones are optional). Instead, from the distro's point of view, these Java apps are being released with a bunch of binary blobs that may or may not contain bugs that need patching later. Which partly defeats the purpose of package management. Python programmers don't do this. Distros love Python, which is why so many of their system administration/automation scripts depend on it. This puts some tension between packagers, who use it as a bash/perl replacement, and developers like Zed, who want to treat it like an up-to-date library -- but realize that the Java solution of just bundling the whole thing with the main app is ugly. That tension exists because Python developers haven't run amok the way Java developers have.

regularfry 16y ago
I'd love to see distros start to introduce (for instance) separate python-sys and python-dev packages. The OS would use python-sys for the admin and automation scripts, but if you wanted to use Python for your own projects, you could use python-dev, which could be a later version. Possibly python-dev could even track upstream more closely. Either way, you'd decouple the system's need for a stable, proven and predictable Python from the user's need for new(er) shiny.
- etal 16y ago
  If pip/Distribute eventually works as smoothly as apt-get, I'll be a happy guy.

regularfry 16y ago

I've come to the conclusion that every language is broken from the point of view of people actually working with the language rather than relying on tools previously written in it. Ruby has broken out of this with rvm, maven kinda-sorta fixes Java but seems to come with a bundle of baggage, virtualenv with your own python build works well enough. CLBuild and QuickLisp, the Haskell Platform and from what I can tell Racket automate a similar approach. I don't know much about the Perl ecosystem, but at a guess I'd say that Perl's backwards compatibility saves it better than most. And this is before you start looking at the code quality and release processes of the libraries packaged in the languages' own distribution mechanisms. Seriously, unless you're working in C/++, I think it's only worth using the system-bundled languages if you're actually targeting the OS itself. If you're targeting more than one platform, using your own build seems to be the only way to stay sane. If you're only targeting a single platform, unless you're tracking a bleeding-edge-style distro like Arch, you can guarantee that all the fun development is going to be going on somewhere you can't reach. Luckily, we have checkinstall.