5 ms·

Yeah, Linux is doing it wrong. I hate that I can't get a new version of python on my machine because the distro maintainers haven't gotten around to it.

panpanna 7y ago
You can.
- sansnomme 7y ago
  Updating and replacing system Python takes tremendous blood and treasure. Compiling python from scratch, updating symlinks, resolving dependency issues and finally debugging the whole thing is no small endeavour. Been there, done that; never again. (This was on a Ubuntu LTS system)
  - Godel_unicode 7y ago
    I've done this dozens of times, didn't seem like that big of a deal? I think the place this might have fallen over is the "updating symlinks" part. Don't replace the system Python, install yours alongside it. They don't need to know anything about each other; aliases in developers profiles and full paths in services/scripts.
    - beatgammit 7y ago
      Yup, stick it in /usr/local and place that in your PATH and Python search path before other dependencies. If you want to be fancy, put it somewhere in your home directory so other users on your same machine cannot be affected. It's really not hard. I do this with other compilers and don't really have issues, though I tend to package it up into a container if I'm going to ship it (e.g. build environment for a team, interpretor for a production service, etc).
  - ben-schaaf 7y ago
    Or you could, just like on other platforms and with other languages, use virtual environments with a version manager such as pyenv for your development environment. Combine that with pipenv and you get pretty painless python development. To be fair, some of this stuff is more recent though.
    - vesinisa 7y ago
      Here is an excellent short blog describing all this and how pyenv and pipenv click together to create a virtual Python environment, that is completely independent of your OS vendor's runtime: https://gioele.io/pyenv-pipenv https://gioele.io/pyenv-pipenv This stuff is definitely quite new, and I guess the need for it has risen as a consequence of all the great new features that have shipped in Python during the last few years. I recently had to write an utility script in Python. I chose to use Python 3 and type hints syntax, requiring at least Python 3.6. This was a problem when I realized some of my team use Ubuntu and Debian versions that ship with Python 3.5 (not to speak of Macs with Python 2.x, but these guys use homebrew anyway). Plenty of time was spent researching virtual environments and writing deployment instructions, and I ended up using pip in pyenv (but stopped short of using pipenv, since creating private distributable packages with it seemed convoluted.)
  - linuxftw 7y ago
    Oh, you mean all that work that package maintainers do for not cost to you? Not to mention there are other distribution tools to acquire a pre-built python release other than installing a .deb.
  - eVeechu7 7y ago
    Go there once, script it, and never do it manually again.
  - cercatrova 7y ago
    You could just use Anaconda or a similar system.
  - acdha 7y ago
    It's hard if you're trying to update the system Python and need to upgrade every dependency for that but if you just want to have, say, “python3.7” in your path it's just a couple of commands: https://docs.python-guide.org/starting/install3/linux/ https://docs.python-guide.org/starting/install3/linux/ ~ $ docker run -it --rm ubuntu:xenial root@b8cda311d766:/# apt-get update -qqy root@b8cda311d766:/# apt-get install -qqy software-properties-common … root@b8cda311d766:/# add-apt-repository --yes ppa:deadsnakes/ppa gpg: keyring `/tmp/tmpe354n0av/secring.gpg' created gpg: keyring `/tmp/tmpe354n0av/pubring.gpg' created gpg: requesting key 6A755776 from hkp server keyserver.ubuntu.com gpg: /tmp/tmpe354n0av/trustdb.gpg: trustdb created gpg: key 6A755776: public key "Launchpad PPA for deadsnakes" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) OK root@b8cda311d766:/# apt-get update -qqy root@b8cda311d766:/# apt-get install -qqy python3.7 debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package libpython3.7-minimal:amd64. (Reading database ... 7603 files and directories currently installed.) Preparing to unpack .../libpython3.7-minimal_3.7.3-1+xenial1_amd64.deb ... Unpacking libpython3.7-minimal:amd64 (3.7.3-1+xenial1) ... Selecting previously unselected package python3.7-minimal. Preparing to unpack .../python3.7-minimal_3.7.3-1+xenial1_amd64.deb ... Unpacking python3.7-minimal (3.7.3-1+xenial1) ... Selecting previously unselected package libpython3.7-stdlib:amd64. Preparing to unpack .../libpython3.7-stdlib_3.7.3-1+xenial1_amd64.deb ... Unpacking libpython3.7-stdlib:amd64 (3.7.3-1+xenial1) ... Selecting previously unselected package python3.7-lib2to3. Preparing to unpack .../python3.7-lib2to3_3.7.3-1+xenial1_all.deb ... Unpacking python3.7-lib2to3 (3.7.3-1+xenial1) ... Selecting previously unselected package python3.7-distutils. Preparing to unpack .../python3.7-distutils_3.7.3-1+xenial1_all.deb ... Unpacking python3.7-distutils (3.7.3-1+xenial1) ... Selecting previously unselected package python3.7. Preparing to unpack .../python3.7_3.7.3-1+xenial1_amd64.deb ... Unpacking python3.7 (3.7.3-1+xenial1) ... Processing triggers for mime-support (3.59ubuntu1) ... Setting up libpython3.7-minimal:amd64 (3.7.3-1+xenial1) ... Setting up python3.7-minimal (3.7.3-1+xenial1) ... Setting up libpython3.7-stdlib:amd64 (3.7.3-1+xenial1) ... Setting up python3.7-lib2to3 (3.7.3-1+xenial1) ... Setting up python3.7-distutils (3.7.3-1+xenial1) ... Setting up python3.7 (3.7.3-1+xenial1) ... root@b8cda311d766:/# python3.7 Python 3.7.3 (default, Mar 26 2019, 01:59:45) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> root@b8cda311d766:/# exit ~ $
choeger 7y ago
Not only is that completely wrong, there is literally nothing in the package manager that prevents you from installing it exactly the same way that you would do it if you did not know about the package manager at all. Sounds to me like you're simply too lazy to do it and to entitled to recognize the value the package maintainers add to your distro.
jsight 7y ago
The way Linux package managers have handled multiple versions of runtimes in the past is definitely wrong. There is a lot of work in this area going on now, though. I think RHEL 8's application streams concept is pretty good: https://developers.redhat.com/blog/2019/05/07/what-no-python-in-red-hat-enterprise-linux-8/ https://developers.redhat.com/blog/2019/05/07/what-no-python... Fedora has an analogue to this as well. It seems like a good move in the right direction.
emidln 7y ago
You can use, today, the same ways that you would force everyone to find/install python (virtualenv, docker, pipenv, conda, whatever is hot this week) in a world without distro-provided python.
opan 7y ago
You could use Guix or Nix to get a newer version.
parliament32 7y ago
If you can't figure out "./configure && make && make install" I think you're doing Linux wrong.
- Too 7y ago
  And then halfway through the compilation you find out you are missing fifteen different dev-packages and the only way to figure out which are by googling obscure error messages. Oh, can't find include efglx.h, you obviously have to apt install libstdglx4-dev. (This was probably written deep on some establish build environment-wiki page that's impossible to find but since you are on Ubuntu 18 instead of 14 it wouldn't have worked anyway because now the package has changed name to apt install glx-dev. Besides - they also forgot to list half of the dependencies required on that page). Figuring out how to establish a build environment for any program you want to install really can't be the best way to do things.
peterwwillis 7y ago
Docker solves that. Yeah, you then have to deal with container problems, but it's the best packaging solution we have at the moment. Maybe one day we'll take the lessons learned and natively build them into the OS, but distros are still obsessed with distro-specific kludges that require extra packaging work. We have great universal packaging when it comes from the community at large, but not from single organizations. Pip is a platform-independent package manager! Why don't we have that for Linux software in general? Because each distro already has their own solution, and they won't work together to build a common one.
- bpfrh 7y ago
  Well there is an effort to solve this with flatpack and snap
  - peterwwillis 7y ago
    Both of which will be dead in 10 years, the former because it's solely focused on the desktop, latter because it's a vendor initiative not a community one.
    - robocat 7y ago
      > latter because it's a vendor initiative not a community one. You may be right, but I don't think you should be quite so cynical. 18.04 has a ten year Long Term Support, and Ubuntu was first released in 2004.
    - Wowfunhappy 7y ago
      > [Flatpak will be dead in 10 years] because it's solely focused on the desktop By this logic, GNOME should have died a long time ago. Focusing on the desktop makes Flatpak better at managing desktop apps. For servers we have, well, Docker.
j88439h84 7y ago
Use pyenv.
kevin_thibedeau 7y ago
You just compile your own from source. Python plays nice with older versions of itself. Use Gnu Stow as a secondary package manager to make it easier to remove or replace.

panpanna 7y ago

You can.

sansnomme 7y ago
Updating and replacing system Python takes tremendous blood and treasure. Compiling python from scratch, updating symlinks, resolving dependency issues and finally debugging the whole thing is no small endeavour. Been there, done that; never again. (This was on a Ubuntu LTS system)
- Godel_unicode 7y ago
  I've done this dozens of times, didn't seem like that big of a deal? I think the place this might have fallen over is the "updating symlinks" part. Don't replace the system Python, install yours alongside it. They don't need to know anything about each other; aliases in developers profiles and full paths in services/scripts.
  - beatgammit 7y ago
    Yup, stick it in /usr/local and place that in your PATH and Python search path before other dependencies. If you want to be fancy, put it somewhere in your home directory so other users on your same machine cannot be affected. It's really not hard. I do this with other compilers and don't really have issues, though I tend to package it up into a container if I'm going to ship it (e.g. build environment for a team, interpretor for a production service, etc).
- ben-schaaf 7y ago
  Or you could, just like on other platforms and with other languages, use virtual environments with a version manager such as pyenv for your development environment. Combine that with pipenv and you get pretty painless python development. To be fair, some of this stuff is more recent though.
  - vesinisa 7y ago
    Here is an excellent short blog describing all this and how pyenv and pipenv click together to create a virtual Python environment, that is completely independent of your OS vendor's runtime: https://gioele.io/pyenv-pipenv https://gioele.io/pyenv-pipenv This stuff is definitely quite new, and I guess the need for it has risen as a consequence of all the great new features that have shipped in Python during the last few years. I recently had to write an utility script in Python. I chose to use Python 3 and type hints syntax, requiring at least Python 3.6. This was a problem when I realized some of my team use Ubuntu and Debian versions that ship with Python 3.5 (not to speak of Macs with Python 2.x, but these guys use homebrew anyway). Plenty of time was spent researching virtual environments and writing deployment instructions, and I ended up using pip in pyenv (but stopped short of using pipenv, since creating private distributable packages with it seemed convoluted.)
- linuxftw 7y ago
  Oh, you mean all that work that package maintainers do for not cost to you? Not to mention there are other distribution tools to acquire a pre-built python release other than installing a .deb.
- eVeechu7 7y ago
  Go there once, script it, and never do it manually again.
- cercatrova 7y ago
  You could just use Anaconda or a similar system.
- acdha 7y ago
  It's hard if you're trying to update the system Python and need to upgrade every dependency for that but if you just want to have, say, “python3.7” in your path it's just a couple of commands: https://docs.python-guide.org/starting/install3/linux/ https://docs.python-guide.org/starting/install3/linux/ ~ $ docker run -it --rm ubuntu:xenial root@b8cda311d766:/# apt-get update -qqy root@b8cda311d766:/# apt-get install -qqy software-properties-common … root@b8cda311d766:/# add-apt-repository --yes ppa:deadsnakes/ppa gpg: keyring `/tmp/tmpe354n0av/secring.gpg' created gpg: keyring `/tmp/tmpe354n0av/pubring.gpg' created gpg: requesting key 6A755776 from hkp server keyserver.ubuntu.com gpg: /tmp/tmpe354n0av/trustdb.gpg: trustdb created gpg: key 6A755776: public key "Launchpad PPA for deadsnakes" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) OK root@b8cda311d766:/# apt-get update -qqy root@b8cda311d766:/# apt-get install -qqy python3.7 debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package libpython3.7-minimal:amd64. (Reading database ... 7603 files and directories currently installed.) Preparing to unpack .../libpython3.7-minimal_3.7.3-1+xenial1_amd64.deb ... Unpacking libpython3.7-minimal:amd64 (3.7.3-1+xenial1) ... Selecting previously unselected package python3.7-minimal. Preparing to unpack .../python3.7-minimal_3.7.3-1+xenial1_amd64.deb ... Unpacking python3.7-minimal (3.7.3-1+xenial1) ... Selecting previously unselected package libpython3.7-stdlib:amd64. Preparing to unpack .../libpython3.7-stdlib_3.7.3-1+xenial1_amd64.deb ... Unpacking libpython3.7-stdlib:amd64 (3.7.3-1+xenial1) ... Selecting previously unselected package python3.7-lib2to3. Preparing to unpack .../python3.7-lib2to3_3.7.3-1+xenial1_all.deb ... Unpacking python3.7-lib2to3 (3.7.3-1+xenial1) ... Selecting previously unselected package python3.7-distutils. Preparing to unpack .../python3.7-distutils_3.7.3-1+xenial1_all.deb ... Unpacking python3.7-distutils (3.7.3-1+xenial1) ... Selecting previously unselected package python3.7. Preparing to unpack .../python3.7_3.7.3-1+xenial1_amd64.deb ... Unpacking python3.7 (3.7.3-1+xenial1) ... Processing triggers for mime-support (3.59ubuntu1) ... Setting up libpython3.7-minimal:amd64 (3.7.3-1+xenial1) ... Setting up python3.7-minimal (3.7.3-1+xenial1) ... Setting up libpython3.7-stdlib:amd64 (3.7.3-1+xenial1) ... Setting up python3.7-lib2to3 (3.7.3-1+xenial1) ... Setting up python3.7-distutils (3.7.3-1+xenial1) ... Setting up python3.7 (3.7.3-1+xenial1) ... root@b8cda311d766:/# python3.7 Python 3.7.3 (default, Mar 26 2019, 01:59:45) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> root@b8cda311d766:/# exit ~ $

choeger 7y ago

Not only is that completely wrong, there is literally nothing in the package manager that prevents you from installing it exactly the same way that you would do it if you did not know about the package manager at all. Sounds to me like you're simply too lazy to do it and to entitled to recognize the value the package maintainers add to your distro.

jsight 7y ago

The way Linux package managers have handled multiple versions of runtimes in the past is definitely wrong. There is a lot of work in this area going on now, though. I think RHEL 8's application streams concept is pretty good: https://developers.redhat.com/blog/2019/05/07/what-no-python-in-red-hat-enterprise-linux-8/ https://developers.redhat.com/blog/2019/05/07/what-no-python... Fedora has an analogue to this as well. It seems like a good move in the right direction.

emidln 7y ago

You can use, today, the same ways that you would force everyone to find/install python (virtualenv, docker, pipenv, conda, whatever is hot this week) in a world without distro-provided python.

opan 7y ago

You could use Guix or Nix to get a newer version.

parliament32 7y ago

If you can't figure out "./configure && make && make install" I think you're doing Linux wrong.

Too 7y ago
And then halfway through the compilation you find out you are missing fifteen different dev-packages and the only way to figure out which are by googling obscure error messages. Oh, can't find include efglx.h, you obviously have to apt install libstdglx4-dev. (This was probably written deep on some establish build environment-wiki page that's impossible to find but since you are on Ubuntu 18 instead of 14 it wouldn't have worked anyway because now the package has changed name to apt install glx-dev. Besides - they also forgot to list half of the dependencies required on that page). Figuring out how to establish a build environment for any program you want to install really can't be the best way to do things.

peterwwillis 7y ago

Docker solves that. Yeah, you then have to deal with container problems, but it's the best packaging solution we have at the moment. Maybe one day we'll take the lessons learned and natively build them into the OS, but distros are still obsessed with distro-specific kludges that require extra packaging work. We have great universal packaging when it comes from the community at large, but not from single organizations. Pip is a platform-independent package manager! Why don't we have that for Linux software in general? Because each distro already has their own solution, and they won't work together to build a common one.

bpfrh 7y ago
Well there is an effort to solve this with flatpack and snap
- peterwwillis 7y ago
  Both of which will be dead in 10 years, the former because it's solely focused on the desktop, latter because it's a vendor initiative not a community one.
  - robocat 7y ago
    > latter because it's a vendor initiative not a community one. You may be right, but I don't think you should be quite so cynical. 18.04 has a ten year Long Term Support, and Ubuntu was first released in 2004.
  - Wowfunhappy 7y ago
    > [Flatpak will be dead in 10 years] because it's solely focused on the desktop By this logic, GNOME should have died a long time ago. Focusing on the desktop makes Flatpak better at managing desktop apps. For servers we have, well, Docker.

j88439h84 7y ago

Use pyenv.

kevin_thibedeau 7y ago

You just compile your own from source. Python plays nice with older versions of itself. Use Gnu Stow as a secondary package manager to make it easier to remove or replace.