[deleted]

limyreth · 2011-04-16 16:36:54

[deleted]

Last edited by limyreth (2019-09-09 13:09:14)

brebs · 2011-04-16 16:54:39

A good idea in principle. Perfectly reasonable.

In practice, the other distros are gonna say something like, "Why should we care what Arch does? It's Arch that wants to be bleeding-edge by making Python 3 the default, they should keep the default as Python 2 like us."

So, best bet to relieve such headaches is to stick to sed-ing in Arch-specific pkgbuilds, and forget the overly-ambitious "Zero Install" - as you've discovered, it means "zero compatibility" rather than "zero problems"

Allan · 2011-04-16 21:17:36

Yes: http://www.python.org/dev/peps/pep-0394/

brebs · 2011-04-16 22:17:33

In that PEP, the definition of "python" is a masterstroke of stupidity. It should of course link to the same as "python2". For hugely-important backwards compatibility

ngoonee · 2011-04-17 08:36:00

brebs wrote:

In that PEP, the definition of "python" is a masterstroke of stupidity. It should of course link to the same as "python2". For hugely-important backwards compatibility

IMO, part of the benefit of using Linux is that developers CAN simply ignore backwards compatibility and get rid of bit-rotten code. That's why 'source code available' is so powerful.

litemotiv · 2011-04-17 08:48:15

ngoonee wrote:

IMO, part of the benefit of using Linux is that developers CAN simply ignore backwards compatibility and get rid of bit-rotten code. That's why 'source code available' is so powerful.

They don't get paid, ergo they can just do whatever they want. IMO that's a lose-lose situation.

brebs · 2011-04-17 09:18:06

Well, sometimes it's desirable despite the pain, e.g. this python 2 vs 3 annoyance.

However, Linux devs in general seem to be roughly 100 times too eager to break backwards-compatibility on a whim. And it turns Linux into a ridiculous mess of incompatible version mixes, e.g. libgdata 0.8 as one of a million examples.

They have too much enthusiasm, and not enough competence. An example is proposing to leave "python" as a "Do ya feel lucky punk?" toss-a-coin-and-hope-for-the-best wildcard, rather than actually specifying a sane version of python to be used. There is a ton of python2 code in existence, and it is *not* going to all be rewritten and tested instantly.

Bah, humbug

ngoonee · 2011-04-17 10:29:59

litemotiv wrote:

ngoonee wrote:
IMO, part of the benefit of using Linux is that developers CAN simply ignore backwards compatibility and get rid of bit-rotten code. That's why 'source code available' is so powerful.
They don't get paid, ergo they can just do whatever they want. IMO that's a lose-lose situation.

Cowboy town, its what I signed up for anyway

Zeist · 2011-04-17 13:18:38

I find it quite baffling that people wouldn't use the latest branch of Python for software which is still actively maintained. Python 3.0 was released in 2008... almost 3 years ago... developers should just get with the program already.

I guess it is a bit of a chicken and egg thing though. Distros won't move to python3 as default since apps aren't built for it... and devs won't move apps since distros aren't requiring them to use python3 to work.

It is not as if python2 is going away, I believe that the arch way in this is the sane approach. Set python3 as the default and leave python2 for legacy support. Assume that applications that are still being maintained will be up to date and anyone who needs older python to run legacy software that is no longer maintained can do so through small tweaks.

I also find it really amusing that python3 is seen as bleeding edge. It is almost 3 freakin' years old.

Ok, so after that unsolicited rant I come to my response to the original question:

Yes, it definitely makes sense that we would assume that developers who are still using the legacy python explicitly state so while people who are using the latest should be able to assume that python = python3.

rWarrior · 2011-05-16 23:12:05

I also agree that 'python' should mean 'python3'.

Before the rest of the community sees the light, here is a dirty fix for those in desperate need to pretend that python means python2. Don't overuse it, lest you fall into the abyss.

Note: This only works if the package uses the following shebang (like ROS):

#!/usr/bin/env python

# Create link to python2 as python in /usr/local
ln -s /usr/bin/python2 /usr/local/bin/python
# Add alias to temporarily to prefer /usr/local/bin over /usr/bin
# Assuming your system is configured to normally prefer /usr/bin over /usr/local/bin
echo "alias use-local='PATH=/usr/local/bin:$PATH'" >> ~/.bashrc
# Commit the change for the current session (or re-login)
source ~/.bashrc
# To run your command, type:
use-local evil.py

Alternatively, you can place the link to /usr/bin/python2 in another directory, e.g. /usr/local/link
And insert that directory at the front of $PATH.

Last edited by rWarrior (2011-05-16 23:24:35)

sitquietly · 2011-05-17 18:06:00

limyreth wrote:

I ran into the issue of python2 applications trying to use python (again)......it makes no sense for python2 applications to use python. I have no real idea what naming schemes other distros are using for this. But none the less, if upstream applications use python2 instead of python then our problems here are over.

Arch devs are not blameless either. I compile all of my arch system from source (except gcc, libreoffice and sage-mathematics) and since the python change I find that apps that use python at compile time are prone to fail to compile in my environment (I suppose that arch devs compile packages in chroot jails). The only way I can create my system without pulling my hair out all the time is to eliminate /usr/bin/python entirely. Any software that tries to use "python" on my computer, at build time or run time, will fail (and then I fix it to use the correct python version). Sometimes I have to edit arch pkgbuilds to call python3 instead of python. Interestingly, many arch python2 packages fail to build in an environment in which python->python3 (perhaps the developer changes python->python2 in the build environment). Right now the idea that all arch packages can be built by any user from the PKGBUILD has been dealt a blow by the change to python->python3 as developers work hard to adapt and still get all of their packages compiled.

I agree with you mostly but I hope that for now developers will always call python2 or python3 explicitly. If "python" exists (and points to python3) a lot of existing code will fail, even arch pkgbuilds will fail.

BTW what kind of stuff are you installing with zeroinstall? I tried it several times over the years, because I'm a long-time rox user, and always got into a mess. Is it working out ok for you? What would you recommend it for?

ngoonee · 2011-05-17 19:10:36

sitquietly wrote:

limyreth wrote:
I ran into the issue of python2 applications trying to use python (again)......it makes no sense for python2 applications to use python. I have no real idea what naming schemes other distros are using for this. But none the less, if upstream applications use python2 instead of python then our problems here are over.
Arch devs are not blameless either. I compile all of my arch system from source (except gcc, libreoffice and sage-mathematics) and since the python change I find that apps that use python at compile time are prone to fail to compile in my environment (I suppose that arch devs compile packages in chroot jails). The only way I can create my system without pulling my hair out all the time is to eliminate /usr/bin/python entirely. Any software that tries to use "python" on my computer, at build time or run time, will fail (and then I fix it to use the correct python version). Sometimes I have to edit arch pkgbuilds to call python3 instead of python. Interestingly, many arch python2 packages fail to build in an environment in which python->python3 (perhaps the developer changes python->python2 in the build environment). Right now the idea that all arch packages can be built by any user from the PKGBUILD has been dealt a blow by the change to python->python3 as developers work hard to adapt and still get all of their packages compiled.

If you're compiling from source it would make sense to build in clean chroots, I'd think (unless you REALLY can't afford the space). I can't say I've run into much of these (then again I don't re-compile repo apps for the fun of it), but I'm sure its a (reportable) bug if a package doesn't build. Most of the python-related packages have the proper sed lines since the switch anyway, so this shouldn't really happen.

rickeyski · 2011-05-17 20:58:57

even when compiling from scratch, I have found a few older aur packages that I needed that used python instead of python2, but for the most part the fix is either a sed 1 liner or add a configure arg and then sed when needed.

What gets really confusing is going from an arch workstation to re-sed everything for use on the ubuntu dev server where python2 is python again. Thats a pain, one day soon I will have an arch beta and dev server to work on. I can dream

sitquietly · 2011-05-18 04:52:33

ngoonee wrote:

If you're compiling from source it would make sense to build in clean chroots

I don't seem to agree.

I don't actually want to control the dependencies

I want to compile packages onto my system with the idea of "this is the environment that you will find actually exists on this computer --- make use of it!" I get a high guarantee that each package has been compiled against the right libraries because each package has been compiled against the libraries that are actually installed on this computer.

Does that make sense? It does seem to work well enough with Arch PKGBUILDs.

Once in a while I see that an arch official package managed to get compiled against an older version of a library that has also just been updated. Then I may have to fix stuff myself; e.g. kdebase-workspace won't compile against the current libgps and I had to apply a fix to the code. But now my kdebase-workspace is compatible with the libgps that is actually installed.

twl · 2011-06-02 22:02:58

upstream should handle this better. every distro should start using python2/3/4 etc... so this can stop being a problem.. it seems to be the best solution

ConnorBehan · 2011-06-09 20:42:28

Yes it usually takes a few years which is why I applaud Archlinux for being one of the first distros to call the python3 binary python. I was initially annoyed by it. Then I realized that I could just make /usr/bin/python a symlink to /usr/bin/python2 for those days when I really didn't have time to figure out what Makefile was causing me problems.

Arch Linux

#1 2011-04-16 16:36:54

[deleted]

#2 2011-04-16 16:54:39

Re: [deleted]

#3 2011-04-16 21:17:36

Re: [deleted]

#4 2011-04-16 22:17:33

Re: [deleted]

#5 2011-04-17 08:36:00

Re: [deleted]

#6 2011-04-17 08:48:15

Re: [deleted]

#7 2011-04-17 09:18:06

Re: [deleted]

#8 2011-04-17 10:29:59

Re: [deleted]

#9 2011-04-17 13:18:38

Re: [deleted]

#10 2011-05-16 23:12:05

Re: [deleted]

#11 2011-05-17 18:06:00

Re: [deleted]

#12 2011-05-17 19:10:36

Re: [deleted]

#13 2011-05-17 20:58:57

Re: [deleted]

#14 2011-05-18 04:52:33

Re: [deleted]

#15 2011-06-02 22:02:58

Re: [deleted]

#16 2011-06-09 20:42:28

Re: [deleted]

Board footer