[Zancarius]

I agree, but I'd guess the chief complaint is that doing so requires the `python2` symlink to be available. There's at least one claim up thread that it doesn't exist on all systems (create it yourself?). I didn't catch the distribution used, but I DID check an older Ubuntu image I have (I run Arch) and there's definitely a python2 link pointing to python2.7 (`python` also points to python2.7 and there's a `python3` symlink that does what you'd expect). So outside some LTS build, it seems surprising to me that it wouldn't exist in 2017 on a modern distro. I still can't shake the feeling that the thread started around a relatively insignificant complaint (dumping Arch because they use Python3 by default? Come on...).

Personally, I'd rather just use `/usr/bin/env python2` to invoke the appropriate interpreter (if you don't need to pass arguments to it), and if the symlink doesn't exist, the onus is on the user to create it. This is ESPECIALLY true for older distros.

Plus, for a sufficiently complicated application, why would someone want to pollute the global site-packages anyway? I'd rather manage most things inside a virtualenv or similar (pick your Python version), because I've seen far too many install_requires/requirements locking to a specific library version.

[CJefferson]

In 2017, indeed everyone has added python2, but I assure you it wasn't that way when Arch originally did the python3 -> python rename.

While this is a small issue, this original thread used it as an example of how Arch is good and pragmatic. To me it seemed like the opposite -- it broke lots of code and packages for no good reason. Why should users of older distros have to add a symlink, when before Arch everyone could be sure that '/usr/bin/python' if present would be python2, and '/usr/bin/python3', if present, would be python3?

Now I agree that using virtualenv or similar is a good idea, but this actually caused the most problems for little 20 line python scripts, because often the users of those didn't even realise they were using python.

[Zancarius]

> I assure you it wasn't that way when Arch originally did the python3 -> python rename.

I disagree. I don't believe it was as painful as some make it out to be. The official packages were updated within a relatively short period of time, and while the AUR packages took longer they're also not officially supported. There was also a news announcement [1]. Honestly, I think of a few other transitions over my years of using Arch as being far, far more painful. The Python2 -> Python3 defaults change isn't one of them.

Although I would agree that Gentoo's approach was somewhat better via eselect, which I believe predated Arch's migration.

> Why should users of older distros have to add a symlink

You're right. That should be the responsibility of the package maintainer. Conversely, why should I, as a developer, have to continue assuming `/usr/bin/python` points to any particular version of Python when most distributions have migrated away from this anachronism? sed does magic, and you really should be using the appropriate symlink for your desired version anyway. Python 3 isn't new. I have a hard time seeing this as problematic because 1) things change and 2) the solution is easy. I'd be happy to entertain a use case where this actually has presented material difficulties, however.

> but this actually caused the most problems for little 20 line python scripts, because often the users of those didn't even realise they were using python.

Well, I do agree: It's a problem for the end user, but the solutions aren't difficult (if someone's using Linux, they probably know enough to fix it). So, either change the hashbang, add a symlink, and--failing that--complain to the package maintainer if it's been packaged up by the distro and the upstream software itself has changed (it should).

My recommendation for developers would be to use the appropriate /usr/bin/python* symlink. Nearly all distros have them in place now (including Ubuntu from a couple years ago). Perhaps assuming /usr/bin/python will always point to a fixed version is a matter of misplaced assumptions.

[1] https://www.archlinux.org/news/python-is-now-python-3/

[AsyncAwait]

> for no good reason.

There was good reason, to move to the latest version of a particular software, since that's kind of the whole philosophy of Arch, in fact the reason I originally switched to it in 2011 was because I had enough of me not being able to use the latest software on Ubuntu.

> Why should users of older distros have to add a symlink, when before Arch everyone could be sure that '/usr/bin/python' if present would be python2

If you made no effort to detect the actual version, it's wrong to assume that. It could've just as well been python 1.

[Zancarius]

> in fact the reason I originally switched to it in 2011 was because I had enough of me not being able to use the latest software on Ubuntu.

It's funny. My reason for switching to Arch was almost the opposite. I grew tired of having to rebuild the latest software in Gentoo every time I updated and ran into someone on Slashdot who encouraged me to give Arch a try. Sure, there's more prebuilt packages, mirrors, etc for Gentoo these days, but then you're in the same boat as everyone else (waiting for the package to be built).

[RUG3Y]

You're right. - If Arch is targeted for power users, what's preventing them from configuring symlinks etc? - Why aren't they using virtualenvs? I never install Python packages outside of a virtualenv.

[Zancarius]

> I never install Python packages outside of a virtualenv.

Global site-packages is all fun and games until someone loses an eye (or a dependency).

I had a fun learning experience with a large Python package once while trying to mix and match dependency versions, simultaneously trying to avoid clobbering the ones already installed by pacman. Without a virtualenv, it quickly becomes impossible to guarantee you won't break something in the process of installing something else. I never made that mistake again.

[hobarrera]

You really shouldn't install global packages circumventing the package manager (this applies to python and everything else really). You're just asking for eventual breakage, or leaking obsolete files.

[Zancarius]

Exactly. In retrospect, I'm actually not sure I've done something quite so stupid in a long time. However, I'm sure I did it ~10 years ago on Gentoo and/or FreeBSD when I was much stupider about dependencies. Either way, what I should've said is outlined below in my last paragraph, and mostly what I mean by polluting global site-packages (with PKGBUILDs!)--and trying not to clobber things.

As an aside first: I sometimes make a PKGBUILD for most things just on the merit that it's better for pacman to manage site-packages on its own--or anything, really. It's a terrible idea to stuff things into global library directories that aren't managed in general (although incautious use of things like npm or pip can certainly do that for you--still an awful idea).

However, I do recommend installing packages into a virtualenv for anything with modest complexity, because some applications have requirements/install_requires that lock specific versions which may not be mutually compatible with others, and there's also the circumstance where official packages aren't new enough but you still want the package manager to maintain the dependent package. I guess you could go with versioned packages in this case, but since the official ones will inevitably find themselves updated at some point, I see it as easier to circumvent the issue in the first place via a virtualenv.

Anyway, I did the above polluting nonsense once when building a package with quite a few dependencies: Trying to maintain a half dozen individual PKGBUILDs just for dependencies and pestering easily a half dozen other maintainers to update their respective PKGBUILDs versus modifying the application's setup.py (either with patch or sed) to match older versions were both terrible ideas and scaled poorly. It's far easier to simply build what's needed in a virtualenv and avoid polluting the global site-packages even with the package manager handling them on its own. This is especially true for complex applications with many dependencies that may already be installed (but with conflicting versions).

Sorry for the rant, you just reminded me and tickled all the right spots! :)