Earlier quoted context omitted.
What I wonder is why one would assume the python command would run python 2, instead of running python 1, assuming python 1 was a thing. By your logic, shouldn't python2, run python3 run python 3, etc. What I'm getting at, is we get used to things being a certain way, but often we're just following a convention that was set in place before we got onboard. Why do we still type "bash" instead of "bash4"?
> Why do we still type "bash" instead of "bash4" Because Bash was made by, and is maintained by, people who understand how backwards compatability in their program is important.
Arch Linux pulls the plug on 32-bit
181–190 of 201 posts
Re: Arch Linux pulls the plug on 32-bit
#182Earlier quoted context omitted.
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.
> 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 br…
Re: Arch Linux pulls the plug on 32-bit
#183Earlier quoted context omitted.
> 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 br…
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.
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! :)
Re: Arch Linux pulls the plug on 32-bit
#184Earlier quoted context omitted.
Debian testing might work. I don't know if it is technically a rolling release distro but it stays up to date. Also OpenSuse tumbleweed. And there's a similar Fedora distro: rawhide, maybe?
Why use testing instead of unstable? (genuine question)
Re: Arch Linux pulls the plug on 32-bit
#185I love the rolling release aspect of arch but I'm looking for something more user friendly. Anybody know of a good linux distro that is user friendly and has rolling releases?
I'm curious why you think Arch is not user friendly? It's not the rolling release since you're asking for other distributions that use that model. I've used my fair share and from what I've seen Arch is by far the most user friendly.
I'm sure Arch for what it is trying to be is user friendly in that sense, but it's not what I'm looking for right now.
Re: Arch Linux pulls the plug on 32-bit
#186Earlier quoted context omitted.
> It was only because of what Arch unilaterally did Arch is a bleeding-edge, latest software kind of distribution. They did not made the decision 'unilaterally'. They made the decision to ship the latest software for their own distribution, as they always do. It may have proven that a lot of software is extremely poor/inflexible, (i.e. rests on weak assumptions), but I am glad Arch moved forward as that showed their…
> They made the decision to ship the latest software for their own distribution, as they always do. As did all the other distributions. Shipping Python 3 is not the issue here. Breaking compatibility with all existing Python 2 scripts is what they did. The two are not mutually exclusive. > I just think that instead of blaming Arch, try to make your scripts more robust, i.e. loop on all 'python ' binaries in /usr/bin.…
The ABI was never documented and at best a convention-enforced one.
Re: Arch Linux pulls the plug on 32-bit
#187Earlier quoted context omitted.
Supporting this view. Got given a Quark SoC based box by someone at Intel. Tried to get something going with it, only to realise I had to use WindRiver Linux. Tried to obtain toolchain for building even simple software for it online, couldn't find it. Asked contacts at Intel: radio silence.
If it's a DK200, then I've built grub to bypass secure boot. You can boot other Linuxes on it (e.g. Yocto) but as per my parent comment, not much will work. I have an SPI image and instructions to flash if you're interested. You'll need an SPI programmer like the ch341a. I think Intel is violating the GPL by not providing sources, since they include a written offer and GPL requires source availability for 3 years. I…
Re: Arch Linux pulls the plug on 32-bit
#188Earlier quoted context omitted.
> They made the decision to ship the latest software for their own distribution, as they always do. As did all the other distributions. Shipping Python 3 is not the issue here. Breaking compatibility with all existing Python 2 scripts is what they did. The two are not mutually exclusive. > I just think that instead of blaming Arch, try to make your scripts more robust, i.e. loop on all 'python ' binaries in /usr/bin.…
The rest of the world explicitly doesn't ship the latest software, check the kernel version in the latest version of ubuntu vs arch, same for GNOME etc. Ubuntu did not even had python3 installed for a long time by default, you had to apt-get it The ABI was never documented and at best a convention-enforced one.
I call your straw man. As I've already repeatedly said, the issue is about breaking ABI, not about what software distributions shipped, nor what they had installed by default. Making /usr/bin/python point to Python 3 has nothing to do with what distributions shipped, nor what they had installed by default. The issues are completely orthogonal. Stop trying to pretend otherwise.
> The ABI was never documented and at best a convention-enforced one.
Upstream shipped build systems that put Python 2 in /usr/bin/python, and Python 3 in /usr/bin/python3. That's about as good a definition of ABI as one gets in the free software world. Arch deliberately patched the ABI. You can try to argue that their decision to do so was correct, even though I disagree. You cannot argue that they didn't know they were changing an ABI when they patched the ABI.
Re: Arch Linux pulls the plug on 32-bit
#189Earlier quoted context omitted.
The rest of the world explicitly doesn't ship the latest software, check the kernel version in the latest version of ubuntu vs arch, same for GNOME etc. Ubuntu did not even had python3 installed for a long time by default, you had to apt-get it The ABI was never documented and at best a convention-enforced one.
> Ubuntu did not even had python3 installed for a long time by default, you had to apt-get it I call your straw man. As I've already repeatedly said, the issue is about breaking ABI, not about what software distributions shipped, nor what they had installed by default. Making /usr/bin/python point to Python 3 has nothing to do with what distributions shipped, nor what they had installed by default. The issues are com…
But it is very much about that. Arch ships latest software, Python 3 is the latest python, python 2 is not. Ubuntu, Debian etc. ship old, outdated software regularly, Arch doesn't.
Because the latest python was python 3, /usr/bin/python pointed there. The other distributions explicitly decided not to ship the latest python.
Prior to Arch making the switch, the 'ABI' was not /usr/bin/python points to python 2, it simply pointed to the latest python release, which on most systems happened to be python 2, because they did not even ship python 3 at all at the time.
You may not agree with the decision, but to pretend like it was "out of nowhere" is unhelpful.
Re: Arch Linux pulls the plug on 32-bit
#190Earlier quoted context omitted.
The switch to the 'python' command running python 3, as a non-arch user, put me off Arch forever. It just broke everything, which had long assumed 'python' would run python 2. Not installing python 2, and just python 3, with the name python3, would have been fine. Arch put us in a situation where it was basically impossible to run python 2 with a #! line, as some distros hadn't yet introduced a 'python2' symlink yet.
The thing is, python guidelines (PEPs) stated that shebangs should specify python2 or python3 explicitly during the transition period. Using "#!/usr/bin/env python" for a project that was python2-only was not following guidelines, so the breakage was really the dev's fault. Also, the python2 symlink should have already been there. Bad packaging on some distros resulted in bad practices packaging by some devs. Don't b…
> Also, the python2 symlink should have already been there.
Nope. There was no such convention or specification at the time. There was, however, convention and specification (in the form of "what Python upstream build systems do") on what /usr/bin/python means, which is "Python 2".