FAIL: Arch Linux switch python executable to Python 3

Today, I got an email from an user of one of my Python scripts asking why the script t does not work on Arch Linux anymore. As it turns out, the Arch Linux team decided to switch /usr/bin/python to Python 3.0 and use python2 for Python 2.X versions. By doing this, they decided to make their distribution incompatible to almost any Python script in the world.

Arch Linux’s decision to diverge from the rest of the world that uses python for Python 2.X and python3 for Python 3.X is stupid. And doing this without updating reverse dependencies beforehand and thus breaking packages in their own distribution is insane. In the end this means that if you use Arch Linux, you should consider switching to a distribution that does things the right way: Debian. You can also switch to Ubuntu, that’s normally just a bit less right (= faster). But using a distribution that does those crazy things in such an irresponsible way is really insane.

Really, how can they be so stupid in the Arch world?


82 thoughts on “FAIL: Arch Linux switch python executable to Python 3

  1. It was a good idea in theory, but very badly executed – no sign of adequate testing, no decent warning period, and a poor solution for backwards compatibility.

    Distros like Fedora have had parallel 2 and 3 Python installs just fine for a while now – Arch doesn’t really have an excuse.

    1. Yea, it was only discussed for over 6 months, and was in testing for something like 3 or 4 months. That’s way too short. It should have been discussed for 3 years minimum, by a 20 member comitee.

      1. “Really, how can they be so stupid in the Arch world?”

        More stupid then you apparently <_<.

        That statement in itself is ironic, your post sounds quite stupid. So let me get this strait you use a explicit path (/usr/bin/python) and expect a version NEVER to change?

        Oh and my favorite part, "if you use Arch Linux, you should consider switching to a distribution that does things the right way: Debian.". Oh right this is just a troll bait post for convincing people to switch to Debian because they do things "the right way" yes endless loops to go through, that sounds right to YOU, not me. How is it Arch's fault that you can't maintain your own script?

  2. If you consider the other packages as scripts and if you want to move to new stable core aka python 3.0
    i think is the right move , this will break all the scripts but it will improve the speed of porting from 2.7 to 3.x

    in my case
    heck kinterbasdb will not work without patches on python 3.0 but it will force developers to speed up the testing on the new python (more users for it)

    you might think as php 4.x to php 5.x switch but that it took longer (years) but someone must decide that is time to migrate all the world to php 5.x

  3. I have no comment regarding this move by Arch Linux’s developers, but I’ve found the transition to be very smooth.

    All packages in official repositories that depended on Python remain working just fine after the transition. Also, all the packages that required Python version 2.* got their dependency updated accordingly.

    The only packages that have problem with the new arrangement is user packages in the unofficial AUR repository and most user-made script. So, no, this change doesn’t causes mass breakage as you’ve described.

      1. AUR (Arch User Repository) works a little different than your normal “repository”.

        It’s more like a web interface that each users can submit and share package.

        From Arch Linux homepage:
        “We complement our official package sets with a community-operated package repository that grows in size and quality each and every day.”

        and from AUR wiki:
        “The Arch User Repository (AUR) is a community-driven repository for Arch users.”

        Basically, while there is a nice web interface for submitting and sharing package, every packages in AUR is produced and maintained by users, not developers. So when changes like this come, it is the responsibility of each users who own packages on AUR to update his/her packages to work with the new Python arrangement. So it is unavoidable that package in AUR will took longer to update then the one in the official repositories that the developers maintains (but even still, if you check on AUR and on the forum, you will see that most popular packages on AUR have been updated relatively quickly).


  4. Hi,

    I am self a hardcore Debian user, but I have a small comment on your post: Congratulations for being an asshole

  5. Now imagine if you’ve done the responsible thing and ported your code to python 3 already.

    IMO Arch did the right thing.

      1. Hahaha.
        I didn’t see your scripts but if anyone would make an ArchLinux package for one of your works, it would package a .py file beginning with #!/usr/bin/python.
        Tested method, you can insert a sed in your PKGBUILD (packaging script file, you don’t know that because you don’t know Arch Linux) doing ‘s/python/python2/g’ and everything will be fine.

        It’s funny to see that you don’t know **anything** about operating systems, bash, and software maintainance. 🙂

      2. Wait, you’re recommending Debian and then complaining that there would be tiny modifications of upstream things in Arch packages to be compatible with Arch?

        Achievement Unlocked: Stupidity!

    1. Now imagine you wanted to port your code to Python 3, but the libraries you need are not ready yet or you are targetting older systems that do not have Python 3 at all (RHEL).

      Naming an incompatible version of a Python the same as Python 2 is major FAIL. AFAIK even the upstream configure scripts default to python3.

      1. Somehow I think that the demographic that runs Arch but targets RHEL, or even Debian Stable, is rather small. They are almost diametrically opposed distributions. And in that rather rare case, you could just symlink /usr/local/bin/python to python2, and use “/usr/bin/env python” in your shebang line and it will work just fine in both RHEL and Arch.

        If Arch didn’t make the leap first, who would? Somebody’s got to jump in first. Eventually, all distributions will, so you should be thankful that somebody is “beta testing” the change for you.

        (Fedora user and Python affectionado here, BTW. Fedora has a separate /usr/bin/python2 in addition to /usr/bin/python and has had it for a while. Not sure why Debian doesn’t have both; not like symlinks take up that much space.)

  6. Well it is not the entire rest of the world.

    On Gentoo, there is both /usr/bin/python2 and /usr/bin/python3. And there is /usr/bin/python which is a wrapper for python 2 or 3 depending on user preference.

    If your script works only with python 2, then you should explicitly call /usr/bin/python2.

      1. Never existed on Debian you mean.

        Having /usr/bin/python always point to the latest/greatest/fastest python is in the interest of users. Distro packagers should make sure that their packages are aware of this. Arch does it in a commendable way.

  7. So from now on, all code that’s python3 in Debian has to use #!/usr/bin/env python3?

    And as python4 will probably not be python1 compatible neither (what python2 had to be, i assume) python4 scripts will have to have #!/usr/bin/env python4?

    In that case, all is fine again when python2 goes away, YAY! (as i assume in Debian python will be reserved for python2 forever?)

    Or, what _is_ the Debian rule for this python symlink?

    Archlinux follows the simple rule, point to the latest (in distro included) stable version.

    ps. But yeah, at least i learned a lesson, follow upstream and use a precise python shebang and forget this distro specific symlink.

      1. So the upstream rule is that python symlink should point to python2 forever and all future versions need to be used as pythonX? (i’m just assuming cause i couldn’t find this info)

        And if upstream never provided python2 before python3 (as you said. i’m no python programmer), i have to say that python should really point to python2. forever.

        Sad for the (from now on) legacy python scripts (on Arch), and from now on we should use python3/python4/etc. shebang to prevent this from happening again?

  8. Even beeing the Debian fanboy I am I have to disagree. Python2 is basicaly dead. I wouldn’t bother with it if I hadn’t to run most of my scripts on Debian, where several of the packages I need are just not there in a python3-version. There is even one I have to nail to an old version because the one in unstable and testing is working with neither python2 nor 3 – namely python-beautifulsoup. So IMHO you should not bash other distros for taking a bold step towards the futur while Debian is not doing such a great job at clinging to the past.

      1. If that was the only change that python 2 scripts needed to run on 3, there wouldn’t be a problem, would there?

    1. Where do you plan on hosting your scripts for the next five years? No competent sysadmin is going to run a box with python3 as the default python for a good while. I suppose you can get a VPS and build your own but what a hassle.

  9. It says on the Arch wiki that system updates are an interactive process – you’re meant to pay attention to what happens. When python was replaced with python3 pacman presented it as a question BEFORE any other package upgrades were offered.

    The transition for me was a simple matter of adding a 2 to any scripts that broke, which was a 5 minute job. But for those of you who don’t like having all your python tools divided:

    2to3 is shipped with python3 on Arch, and should convert pretty much everything with no issues. Honestly this change is GOOD as far as I’m concerned. Someone had to do it, and Arch is an excellent distro. This change is the kind of thing we moan at companies like Microsoft for NOT doing.

  10. i just pacman -Syued a couple of days ago and everything works properly and how hard is it to symlink python2 and python?

  11. hey tardy, python itself is moving to python3… how dare the python team be so irresponsible!

    the move to python3 was announced (by the python team) quite a while ago and they helped do it smoothly through deprecation and warnings in 2.6 and 2.7… it’s the rest of the world’s fault (read: your fault) if they didn’t listen back then and suddenly found distributions moving to 3…

    1. No one has problems with /usr/bin/python3, just with /usr/bin/python being equal to it. Moving /usr/bin/python while upstream recommends /usr/bin/python3 and everyone else uses python3 is not correct.

  12. A debian fanboy who’s ranting about another distributions gutsy move to push an upcoming technology that they themselves are too afraid to make…
    So, what else is new?

  13. (I can’t reply to your comment above)
    Oh, so a shabang edit is a “modification to the upstream source”. Exporting a different ‘PYTHON’ env var could be better?
    There are a lot of fix for this, and they can be done in a variety of methods, from modifying **the shabang** (not the entire source, don’t make me laugh), to changing your symlink, or exporting a different environment variable. Arch is a user-centric distro, so far from Debian and Ubuntu, you can’t compare them, because they’re completely different in the philosophy.

    And about “modifying” the source… good point, Arch uses less patches than Debian 😛

    1. > Oh, so a shabang edit is a “modification
      > to the upstream source”

      Of course it is.

      > Arch is a user-centric distro, so far
      > from Debian and Ubuntu
      Arch does not seem to care about users, it just broke all user Python scripts. In contrast, our priorities are our users and free software, as stated in Debian Social Contract paragraph 4.

      python3 does not provide the same API previous versions of python provided, so pretending that it does is just wrong. That’s something we don’t do.

      > And about “modifying” the source… good point,
      > Arch uses less patches than Debian

      (1) Not everyone can be as excellent as Debian
      (2) Since Arch will patch every Python script now, it should reach Debian’s number easily

      1. You are from a completely different philosophy of distro-development, so I cannot expect you to understand my words.
        You are talking about concepts that are not intended as targets for us: the user in an Arch environment builds the OS, so the guy that reported you this news is simply a… noob?
        First, every Arch Python2 software works out of the box. You don’t need to patch anything, you can easily export a different python env variable. Second, if you upgrade to Python3 inserted as a default option, you can always have the Python2 solution as a fallback option or a choice for the software written in Python2.
        Everything works fine, Arch is not the kind of distro that is burned, installed, and BAM you have it. The target is completely different, we provide a toolkit to a power user to make his system, if he links /usr/bin/python to python2 there won’t be developers crying because Python3 is the default now – contrairly, the user will receive support on forums and IRC because, in the end, that symlink is a CHOICE of a user, not a choice of a nazi-developer. You can change, you can fall back to the working solution, I don’t see the problem.
        Oh, I see… the noob crying for a script that doesn’t work is the problem, here. Not our development philosophies 😉

      2. The upstream source should not add the shebang, it should use setuptools or distutils, and the shebang is added according to what interpreter pip/easy_install/ are using.

        For example, if you did it correctly, using “python2 install” would make sure the shebang used python2.

        So, while I am not a huge fan of the Arch decision, I am not a fan of lazily made python programs either.

    1. This is by far the worst rant and most stupid post I’ve ever found on
      Sorry but how on earth can you rant in such a crude way against someone making a bold move that might have been long overdue, just because the big distros for non power users can’t make such a move because it would break them, means a distribution targeted at an audiance that is aware of version differences and fixes can do it and does it.
      A command should always launch the version that is the newest stable version in the distribution. Also note that yes there was enourmous planning going on, I’m a regular reader of Arch mailinglists and the move has long been planned, had it’s own repository and was in testing for quite a while.
      It’s not Arch’s fault that the correct way to do things ain’t possible for the big ones and please keep your arguments less atacking next time.
      Arch is not Debian and doesn’t want to be Debian as pointed out earlier it’s offical policy to stay at the bleeding edge (remember next time you get a new kernel months after release that it were the brave Arch devs/testers/users who made sure it works on your super stable distro potentially saving everyone relying on a lot of stability much pain.
      I always think about Arch users and developers as the first row in a system that makes sure that everyone gets good and stable software. This also means that Arch users generally are people with the skill to fight the little problems that might arise from new software.
      So please take this into account next time

      1. Even subscribed to the testing/ repository, I’ve only ran into one issue in 2 years, when extra/libpng was replaced with testing/libpng leaving SLIM unusable.

        As Niklas said; Arch is a very involved distribution, you have to build it from nothing. I can understand this being an issue in a distro like Ubuntu which is meant to be easy to setup, easy to use, and require little know-how to get started (I couldn’t imagine how much pain this would cause someone who had only ever used the terminal to follow install guides). Arch on the other hand is a bleeding edge rolling release distro, and It’s likely 98% of its users using it will find this transition smooth as eggs.

        Agreed: Extremely stupid post.

      2. I completely agree (my blog post is against this and not against Arch), Arch Linux is bleeding edge and users know that. For example, I don’t like GNOME-Shell, but I know that when GNOME3 will be officially released, we will have it immediately in [testing], so GNOME2 fans will have to find a way to maintain that, maybe with an external repo. I will not cry and rant “baaaah Arch killed my favorite desktop environment baaaah ç_ç” because I know what using a bleeding edge distro means.

  14. Kudos to the Archlinux Team!

    My system works excellent before and after the upgrade, maybe is just because I dont use any of your scripts. =)

  15. I understand that people react aggressively towards being called dumb, but I still think that letting /usr/bin/python point to python3 is wrong.

    I have lots of small personal python scripts lying around, written before python3 was generally known to break backwards compatibility, and if I were an Arch user and not a Gentoo user, all these scripts would be broken, now.

    I now write almost all new code in Python 3, and I clearly prefer Python 3 to Python 2.x, but I don’t want to edit all my old scripts, because my distro decides that I should now use Python 3 by default. To me that’s just a sign of paying no heed to the users, regardless of how often you call the distro a users distro.

    Instead of switching /usr/bin/python to python 3, the proper way to go would have been to simply switch all python packages which have python 3 versions to use python 3.

    Just do the math: You have many users and far fewer distro maintainers. Switching /usr/bin/python to python 3 requires every single user who has custom python scripts lying around to check every script or get annoyed at the breakage.

    And it’s not like this gives a user any advantage. Is the one keystroke you save on typing python as opposed to typing python3 really worth the hassle of breaking all custom python scripts your users use?

    Worse: It may make Arch users use #!/usr/bin/env python in the shebang if they want python3, and when we switch to python4, every single one of those scripts will have to be edited again.

    All the py3 scripts written on distros which have py2 as default will keep working after the switch to python4, though, because they include the version in their shebang.

    But well, if Arch users want the breakage, it’s their choice…

    1. I’d like to understand your view little better. Mostly, I don’t understand the idea that pointing ‘python’ to ‘python3’ is going to break so much. I consider myself a pretty heavy python user. Most of my development is done in python, a good half of my personal scripts are in python, my window manager and several components also rely on python.

      The update DID of course cause many of these things to stop working, but ‘break’? But is it really ‘broken’? It’s a simple matter of appending 2 to anything that has broken. This doesn’t mean you have to spend a few hours going round your system doing this, just fix as you run into the issues. (I have now run most of my scripts through 2to3). It just doesn’t seem like such a crippling move to me.

      Besides, the more important question for me is – when do you suggest then that python point to something newer? When we reach python4, what then? Should python still be pointing to python2? Are we supposed to wait until more supports python3? Plenty of scripts won’t be (especially your own). Is the work of pointing all your old scripts when this happens to python2 supposed to be less work?

      The most interesting thing about this switch is that I haven’t seen many Arch users complain about this, in-fact most of the people I’ve seen defending this move are Arch users (myself included). And similarly, the main people who seem to think this is a bad move are non-Arch users (you Arne, and the article writer are examples).

      1. “The most interesting thing about this switch is that I haven’t seen many Arch users complain about this, in-fact most of the people I’ve seen defending this move are Arch users (myself included). And similarly, the main people who seem to think this is a bad move are non-Arch users (you Arne, and the article writer are examples).”

        Exactly, lol

      2. Well, as I said: If Arch users like it that way, they shall have it. It’s not the way I want it. The only things which should break are those which I intentionally get as testing. But please, if an Arch user uses one of my scripts and it doesn’t run because it assumes that /usr/bin/python is python 2.x, send him/her to the Arch maintainers.

        … well, that likely won’t happen, so it seems others will have to do some of the maintenance work for the Arch maintainers, which likely is the reason, why Julian is so pissed by that move.

      3. I’m sorry that Julian had to deal with a single user who wasn’t smart enough to follow the Arch guide and actually pay attention when updating, but it really is not as big a deal as this article makes out.

        And like you say, if you don’t want to have to deal with these things then you should not be doing something stupid like using a bleeding edge distribution. Julian is paying for the idiocy of users, not Arch – this move fits right into the Arch philosophy and is something all of It’s users (and from the amount of Arch users I’ve seen defending this compared to the one idiot Julian delt with) will have absolutely no problem with – should have no problem with because of the nature of Arch.

        My issue with the Article is that the hate is directed at Arch, rather than the user. You would have to have paper stapled to your face to miss all the warnings on the Arch site about this being the Arch way. In-fact just to nail that in:

  16. Then, the _future_ Squeeze, will get the _old_ bash4 as /bin/bash4 ?

    We have enought shit in the planet-debian feed with tha canonical fanboys, to get addons like launch crap to Arch Linux without understand the issue.

    Years ago, a more clever exposition, documentation and solution to the isue than this post, was expected for a Debian Developer.

    Nowdays, there is a LOT OF STUPID things in Debian at first place, at an enterprise level I could say. So no more things than CRAP are expected y some (still) Debian users.

    Have a nice day.

  17. Their just trying to do the right thing. I use th AUR extensively and haven’t noticed any obvious deficiancy’s. I agree that they should have given more warning but arch is all about being cutting edge, python3 is the ‘latest’ python and 2.7 was the last major legacy release, the decision to switch seems sensible enough to me.

  18. When that python 3 upgrade came, all the official packages worked just fine, the packagers did a great job of converting.

    I did have two AUR packages that I had to recompile, but the only thing i did was add a “2” in two places — hardly very difficult for someone who has managed to install Arch Linux in the first place 😉 Then, because I am an Arch Linux user, I notified the maintainers of those two AUR packages that they should add that “2” in their scripts. But AUR is, as Arch says everywhere, meant to be handled with care, it does not in any way have officially supported packages; you are expected to have to work a bit once in a while on them.

    Arch is not stupid, it Keeps It Simple, Stupid; instead expecting its users to be smart, or at least persistent… 😉

  19. As long as you can install python2 and python3 in
    parallel, python3 is not really an upgrade to
    python2 (same with sqlite2 and sqlite3).

    That’s why JAK is correct and $PREFIX/bin/python
    must be Python 2, and Python 3 scripts must use
    「#!/usr/bin/env python3」 instead.

    And, upstream also says so. So please, people,
    stop trolling. This may be a rant rather than
    an objective post, but that doesn’t change the
    fact that he’s right.

  20. Hi there. That is one of the reasons the KDEmod team forked ArchLinux in Spring 2010. In our repositories there is still python 2.6 and we will update to 2.7 soon.

    Testing repository we are working hard at the moment to get 0.3.0 of Chakra GNU/Linux this Winter out.

    When I or my team adds new pkgs like Xorg or even kernel related we always create new repositories which you can put on top of you testing repositories.

    If you want to have a stable system, then you can use our stable repositories we only update with our major releases. Only security fixes or point-releases which are fixing troubles in stable get updated there.

    We struggled a long time with Arch. Now not any more 😉

  21. I think my sentiments have been more than adequately communicated above. But, in the spirit of community I give my +1 to the douchebag vote.

    I run Arch and have had very little problem with the migration to python3. When I do have issues (it has only been when compiling), I simply swap the symlink from python3 to python2 and back again.

    Really, it’s not that big of a deal.

  22. You should go to their page and see what ArchLinux is all about. And if you dont want to use python 3, you can always go back to pytrhon 2 till you feel ready. Please inform your self before unfounded bashing of one of the most fantastic and original distributions out there.

  23. First of all, this isn’t a minor update, so no, you don’t have to change your code on every new upstream patch.
    Second, you’re lazy, you’re crying like a girl for something you will need to do in the near future.
    Third: the guys are clearing the path to others to follow or just see how they did it
    And fourth, stop thinking as a dinosaur, we are at 2010 and changes are and will be even faster in the future.

    Stop complaining about your littleness 😀

    1. martin: Your answer is one from someone not using your distribution in Enterpsise size installations.

      REAL OS:es/distribution take API compliance seriously.

      So if you and the distribution that you use is fine with API breakage, it is ok. But others need to run programs from last century.
      Different use cases, different sollutions. Julian should have acknowled this too.

      1. Hi Anders!

        Yes, at this time I’m a (amateur) home user who enjoys Arch and it’s philosofy a lot, but if I were to administer several servers or even clusters take for sure I would kept for a long time from now old Python 2 for compatibility reasons.

        This is an easy thing to do, just ignore new Python package and don’t upgrade them.

        A community project named ArchServer will gonna address all this issues.

        “So if you and the distribution that you use is fine with API breakage, it is ok.”
        This isn’t true. I have a lot of packages installed from AUR an only one, Calibre, was breaked because this transition. Again as someone else said above, a simple sed on every .py files solved my day. Arch Linux devs are not very keen to break anything, in fact, an AL installation can last for YEARS without serious downtimes. I’m very sorry about debianers but Arch is in fact as stable as Debian with all the great things that makes Arch to be Arch 🙂

        “But others need to run programs from last century.
        Different use cases, different sollutions. Julian
        should have acknowled this too.”
        Productivity environments don’t usually need “bleeding edge” technology but on the other side yo can’t condemn the rest of the world to live literally in-the-past as is the Debian way.


  24. Oh Dear,
    my python script does’nt run on DEBIAN !!
    Ahrrr, they use Python 2 !
    What about my script in Python 1 !!!


  25. Hey, you know, python2 is a starting to die already. The worlds isn’t as debian stable users would wish it, a frozen world with nothing else than security updates. You might be shocked by this practice, ’cause debian won’t do this in less than ten years, I bet, but this is the Arch Way, considering that things aren’t carved in stone, and trying to open a path for the move.

    Python is moving, and it will be time to switch your scripts to something compatible python3. But, even if you don’t want to, I think Arch will still keep python2 in the repos for some time.

    “Arch Linux’s decision to diverge from the rest of the world that uses python for Python 2.X and python3 for Python 3.X is stupid.” Well, sorry for not being a sheep, it’s just logical, python 3.0 was released almost two years ago already, so, yeah, I think it is a good time to switch. Most programs I use are already python3 compliant (ranger, poezio, my own python scripts, etc…). Needless to say, libs like sleekxmpp can use both, depending of the version of python you run the with (an this is GOOD practice).

    Oh, also, your user should read the news (Arch users SHOULD do this before complaining to anyone), and learn to edit a text file, things that get broken by that update can be fixed by adding a “2” at the end of the shebang. Not really much of an issue here…

    1. Why switch name at all?
      There is a brackage of the API, so why not continue using python for python 2 and python3 for python 3? All are going to use python3 anyway to get the new API:s, and python will slowly fade away in favor of python3.

      Anyway, Debians definition of users is different from Arch definition of users. Julian should have acknowled it in his post and Arch people should also do that.

  26. This is indicative of a broad social problem with coders. We’re too stupid to check that our work won’t break down the line, even though it WILL happen. We don’t assume that one day “python” might not mean python 2, and don’t stop to think that using “python26” might be wise if we’re developing for python 2.6.

    But still, it’s easier to flame arch for making the call they will eventually have to make, thus forcing devs to get their acts together before a larger distro changes as well. So kudos to arch for kicking me in the balls and making me do my job properly.

  27. I will admit that the change caught me by surprise, solely cause I am a noob who built my own linux through arch. I am simply going to stick with python2 until python3 becomes more stable. yes this did break, so to speak, some of my programs, but as all arch users do, I fixed it. I switched to arch cause I wanted to get to know how linux OS systems basically works, now I do. I was a debian user for quite some time but did not like the slow retrieve of certain packages and their rules of what we could use and not use i.e. firefox. So I switched and am happy for it. The update to python3 is a good thing but for me to early. Yes, I should’ve looked before at the update before I said yes, that is the noob in me. Even though I have to constantly look under the hood of my Arch linux and do some fine tuning, i also am not complaining of the up to date way Arch keeps us in. It is really up to me, whether I want to go that way yet. In time, I will convert to py3, but not now, cause it is my choice. Plus I don’t think py3 is complete yet, I had probs in the beginning b4 I made the decision to stay with py2 of having py3 import pygame. There were no answers as to why, when I checked the net, so for now, I stick with py2 and look forward to loading py3 when I’m ready.

  28. I kind of agree with the original post, the python change caught me by surprise.
    I guess for a linux distro is important to clearly state what is it’s niche. Sudden changes like this with python, makes me think Arch is distro for beta testers or people who like to tune their system all the time… I personaly got tired doing that.
    I have daytime job as programmer(payed) 🙂 and prefer to have rock solid system at home, not a tamagochi which needs daily care 🙂 So i’ve switched to a more conservative distro 🙂

  29. So basically, if debian does one thing wrongly.. all distributions doing it right instead, are wrong for debian users.

    Nothing to see, move along, yada yada

  30. Arch is user centric. It is CENTRED on the USER to manage his own system, and if need be, inform developers who are too lazy to make their scripts compatible with the latest recommended standard version of whatever they depend on. I pity the fool who would abandon the Arch way, heck, any Linux philosophy for another just because of a single script. Perhaps 3 months from now you will be cursing Debian because default python is 2…point 1.
    I can only use Debian under 1 circumstance. I need some repo to get a compiled package which I need to downgrade.

  31. “OMG why is /usr/bin/python pointing to python2?!?!?!! My scripts are only python1 compatible GAHHH! Bleeding edge distro should point /usr/bin/python to python1 and leave python2 to daredevils!!1!!!one!”

    Seriously, if you insist that /usr/bin/python points to python2, what would happen when python4 is out? Why is “2” a special number and not 1? or 3? or 4? When should the switch from 2 to 3 happen? 3 years from now? 10 years? A century? Until we have zero script on the internet that does not work with Python3? You can’t possibly eliminate all scripts out there that isn’t python3-compatible. I don’t see the logic in this.

    And if you’re managing a huge infrastructure with stability being the most important aspect, why use Arch to begin with? It’s like taking your grandmother to a rock concert. You’re just the wrong user for Arch.

  32. Aw, come’on! You develop for the most pathetic, bureacratic and ankward distro in history and frak ’bout Arch?
    Please make a good thing to you and sharap, loser.

Comments are closed.