5 ms·

> Want python later than 3.6? Not in the box. The more I use linux (and I'v been for almost 15 years), the more strongly believe that using what the Linux dist

> Want python later than 3.6? Not in the box. The more I use linux (and I'v been for almost 15 years), the more strongly believe that using what the Linux distros provide as a development toolchain is an antipattern. Use separate toolchains with SDKs separate from your /usr instead. > Good for what it is, bad for compiling large numbers or packages. at worst you can docker run -it aarch64/ubuntu on your desktop and compile your stuff there.

Yajirobe 6y ago
u can use virtual environments for that
- giancarlostoro 6y ago
  In the case of 'Python Virtual Environments' you'd still have to install another version of Python which is non-trivial with Debian based systems without causing some sort of collision, unless you download the binaries to /usr/ or other bin location as suggested.
  - TYPE_FASTER 6y ago
    I like to use pyenv for this purpose, as it "virtualizes" Python versions by installing them locally as you mention. Then you just point each virtualenv at the Python binary for the version installed via pyenv. pyenv + virtualenv + virtualenvwrapper have greatly reduced Python dependency issues for me.
    - giancarlostoro 6y ago
      A bunch of programming languages do a little bit similar like Node has Node Version Manager or nvm, I think Go has GVM, Rust just has Rust Up, they usually install in your home folder and let you swap between versions globally, I've yet to have to do this as I usually spin up a VM if I know I'm going to need to deploy to a very specific version of Debian / Ubuntu, a virtual environment might not match behavior on the actual target system but a VM definitely will.
    - fidelramos 6y ago
      +1 to pyenv. And it's even better if you combine it with pipenv [1]: pipenv manages dependencies its own file (Pipfile) which can also specify the required Python version. Pipenv integrates with pyenv so if the required Python version is not available it will offer to download and install it. Tldr; with pyenv and pipenv installing a Python project is just "pipenv install". [1] https://pipenv.pypa.io/en/latest/ https://pipenv.pypa.io/en/latest/
      - strbean 6y ago
        I would strongly recommend taking a look at Poetry as an alternative to Pipenv. Pipenv is honestly a nightmare.
        kstrauser 6y ago
        I regret I can only upvote this once. Pipenv still gets press, but I'm not sure why. Every senior dev I know switched to Poetry long ago.
        fidelramos 6y ago
        I have been using pipenv only on a couple of projects and for a few months, but it has been an improvement over pip and virtualenv. Why do you say Pipenv is a nightmare? Have you had bad experiences with it?
  - beagle3 6y ago
    Especially in the case of a python virtual environment, "conda" solves everything ultra cleanly (regardless of whether it's debian, fedore, arch or Windows and probably macOS too though I didn't try). It provides any version of Python, regardless of what your base system has (or lacks). It also provides an isolated gcc and many other packages; and you can still "pip install" inside it if the package you need is not conda-native, and conda will track it just as well. Conda is really underappreciated.
  - freeone3000 6y ago
    It's totally trivial. ubuntu 18.04 has packages for python3.7 and python3.8 which install to /usr/bin/python3.7 and /usr/bin/python3.8, leaving /usr/bin/python3 pointing to /usr/bin/python3.6. So, you'd type: `sudo apt -y install python3.7` Then: `mkvirtualenv --python $(which python3.7)` It really is that easy.
- amelius 6y ago
  Perhaps virtual environments should be the default on Linux distributions?
rowanG077 6y ago
Please take a look at Nix. I think you will like it.
LeifCarrotson 6y ago
I totally agree, at least on the desktop. My /usr isn't required for any of my customers' projects to run, and it probably shouldn't be - I have environments and VMs and containers for all that stuff. But this is an SBC. It's likely to be configured to run its specific task forever. It should automatically log into the default user's account, and automatically start whatever software you want it to run. Software for it is likely to come from cross-compilers and to be sent over SSH. It doesn't have hundreds of gigabytes of high-speed storage, the entire OS needs to be copied from a microSD card on every boot, so you don't want to have multiple toolchains on it. I really like the DietPi [1] environment for these purposes (though it doesn't currently support have the Jetson Nano), the setup scripts make it easy to configure the OS for exactly the tools you want. [1]: https://dietpi.com/ https://dietpi.com/
barumi 6y ago
> The more I use linux (and I'v been for almost 15 years), the more strongly believe that using what the Linux distros provide as a development toolchain is an antipattern. Your assertion makes no sense. Let me explain why. You've adopted a LTS release which was made public 2 years ago, was already a couple of years in the making, and is aimed at establishing a solid and reliable base system that can be targetted by the whole world with confidence. And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure? Unless you're planning on managing that part of the infrastructure for your customers to use, your race to catch up with the latest and greatest makes zero sense, and creates more problems than those you believe you're solving. And no, it's not an infrastructure problem. It's a software engineering problem that's yours in the making. If you seek stability and reliability then you target stable and reliable platforms, such as the stuff distributed by default by LTS releases such as Ubuntu 18.04. because that's what they are used for.
- jcelerier 6y ago
  > You've adopted a LTS release which was made public 2 years ago, was already a couple of years in the making, and is aimed at establishing a solid and reliable base system that can be targetted by the whole world with confidence. From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release. They just want a quick linux install to run their shit on, or it was handed that way by the Uni department / company / whatever. Or just because it's the biggest name and you're sure to find help online. And then a lot of people don't upgrade - I work with my fair share of people running win 7 (even still have an XP person around), OS X < 10.10 and Ubuntu 14.04, just because they can't afford newer hardware required to make the experience of newer OSes not a laggy shitfest. > And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure? gcc is not part of infrastructure, just like Xcode.app or Visual Studio aren't part of Windows or macOS infrastructure.
  - my123 6y ago
    gcc is part of the infrastructure, for the simple reason that you need the same compiler version to build Linux kernel modules.
sergeykish 6y ago
The more I use linux (12 years), the more I believe that common users should not use "stable distribution". Upgrade is risky, software is always outdated. It solves nothing and provides unjustified feeling of stability. LTS makes sense as deployment platform. Push it to server and deploy own application. Make a demo like subject NVIDIA Jetson Nano SDK and forget about it. There are better ways to help underpowered machines - use light desktop environment, block ads in browser, add RAM if possible. Kernel and base requirements has not changed much in a decade. About 120 MB with XOrg.
- rektide 6y ago
  this feels like mass cowardice to me. run Debian testing or unstable. run something semi modern. not old lame vendor LTS. those who cower in LTS land, thinking they are saving themselves from troubles have very very very little experience, scant little too contribute to the community that cares & tries to remain mildly up to date. there is such a prevalent fear based mentality about running decent reasonable modern upstream software but it is such FUD, such a cannot do attitude. rarely can these camps justify their afraid behavior. LTS is nonsense. testing, unstable, they work well, & they expose real honest levels of support for systems, versus relying on antiquated but known support that LTS brings the tepid adopters.
  - sergeykish 6y ago
    It is in the name, marketing, people use Debian Stable, Ubuntu Long Term Support, they don't use Ubuntu Outdated. But that's what it is. The moment it moves to Stable it does not receive versions update. We can't force rename. Maybe we can come up with better names for "testing", "unstable"? * Fresh * Upstream * Rolling I understand people don't want to switch distribution, channels out of fear, inconvenience. Can cross-platform package manager help? The one with dependency resolution — Nix, not the one that bundles it all together like Flatpak or Snap.
rektide 6y ago
this is godforsaken mother-of-all-anti-pattern sinful words. how terrible! don't trust the distro, don't trust upstream! trust only the particular bizarre awkward vendor tool chain? gods no. heavens no. the only reason, the only places this advice is ok is when your hardware is unsupportable, un-un-streamable, when the hardware embodies an anti-supportable form of existence. @jcelerier's advice here could not be more antithetical to the real story. if you need custom weirdo toolchains, something has gone direly wrong.

Yajirobe 6y ago

u can use virtual environments for that

giancarlostoro 6y ago
In the case of 'Python Virtual Environments' you'd still have to install another version of Python which is non-trivial with Debian based systems without causing some sort of collision, unless you download the binaries to /usr/ or other bin location as suggested.
- TYPE_FASTER 6y ago
  I like to use pyenv for this purpose, as it "virtualizes" Python versions by installing them locally as you mention. Then you just point each virtualenv at the Python binary for the version installed via pyenv. pyenv + virtualenv + virtualenvwrapper have greatly reduced Python dependency issues for me.
  - giancarlostoro 6y ago
    A bunch of programming languages do a little bit similar like Node has Node Version Manager or nvm, I think Go has GVM, Rust just has Rust Up, they usually install in your home folder and let you swap between versions globally, I've yet to have to do this as I usually spin up a VM if I know I'm going to need to deploy to a very specific version of Debian / Ubuntu, a virtual environment might not match behavior on the actual target system but a VM definitely will.
  - fidelramos 6y ago
    +1 to pyenv. And it's even better if you combine it with pipenv [1]: pipenv manages dependencies its own file (Pipfile) which can also specify the required Python version. Pipenv integrates with pyenv so if the required Python version is not available it will offer to download and install it. Tldr; with pyenv and pipenv installing a Python project is just "pipenv install". [1] https://pipenv.pypa.io/en/latest/ https://pipenv.pypa.io/en/latest/
    - strbean 6y ago
      I would strongly recommend taking a look at Poetry as an alternative to Pipenv. Pipenv is honestly a nightmare.
      - kstrauser 6y ago
        I regret I can only upvote this once. Pipenv still gets press, but I'm not sure why. Every senior dev I know switched to Poetry long ago.
      - fidelramos 6y ago
        I have been using pipenv only on a couple of projects and for a few months, but it has been an improvement over pip and virtualenv. Why do you say Pipenv is a nightmare? Have you had bad experiences with it?
- beagle3 6y ago
  Especially in the case of a python virtual environment, "conda" solves everything ultra cleanly (regardless of whether it's debian, fedore, arch or Windows and probably macOS too though I didn't try). It provides any version of Python, regardless of what your base system has (or lacks). It also provides an isolated gcc and many other packages; and you can still "pip install" inside it if the package you need is not conda-native, and conda will track it just as well. Conda is really underappreciated.
- freeone3000 6y ago
  It's totally trivial. ubuntu 18.04 has packages for python3.7 and python3.8 which install to /usr/bin/python3.7 and /usr/bin/python3.8, leaving /usr/bin/python3 pointing to /usr/bin/python3.6. So, you'd type: `sudo apt -y install python3.7` Then: `mkvirtualenv --python $(which python3.7)` It really is that easy.
amelius 6y ago
Perhaps virtual environments should be the default on Linux distributions?

rowanG077 6y ago

Please take a look at Nix. I think you will like it.

LeifCarrotson 6y ago

I totally agree, at least on the desktop. My /usr isn't required for any of my customers' projects to run, and it probably shouldn't be - I have environments and VMs and containers for all that stuff. But this is an SBC. It's likely to be configured to run its specific task forever. It should automatically log into the default user's account, and automatically start whatever software you want it to run. Software for it is likely to come from cross-compilers and to be sent over SSH. It doesn't have hundreds of gigabytes of high-speed storage, the entire OS needs to be copied from a microSD card on every boot, so you don't want to have multiple toolchains on it. I really like the DietPi [1] environment for these purposes (though it doesn't currently support have the Jetson Nano), the setup scripts make it easy to configure the OS for exactly the tools you want. [1]: https://dietpi.com/ https://dietpi.com/

barumi 6y ago

> The more I use linux (and I'v been for almost 15 years), the more strongly believe that using what the Linux distros provide as a development toolchain is an antipattern. Your assertion makes no sense. Let me explain why. You've adopted a LTS release which was made public 2 years ago, was already a couple of years in the making, and is aimed at establishing a solid and reliable base system that can be targetted by the whole world with confidence. And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure? Unless you're planning on managing that part of the infrastructure for your customers to use, your race to catch up with the latest and greatest makes zero sense, and creates more problems than those you believe you're solving. And no, it's not an infrastructure problem. It's a software engineering problem that's yours in the making. If you seek stability and reliability then you target stable and reliable platforms, such as the stuff distributed by default by LTS releases such as Ubuntu 18.04. because that's what they are used for.

jcelerier 6y ago
> You've adopted a LTS release which was made public 2 years ago, was already a couple of years in the making, and is aimed at establishing a solid and reliable base system that can be targetted by the whole world with confidence. From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release. They just want a quick linux install to run their shit on, or it was handed that way by the Uni department / company / whatever. Or just because it's the biggest name and you're sure to find help online. And then a lot of people don't upgrade - I work with my fair share of people running win 7 (even still have an XP person around), OS X < 10.10 and Ubuntu 14.04, just because they can't afford newer hardware required to make the experience of newer OSes not a laggy shitfest. > And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure? gcc is not part of infrastructure, just like Xcode.app or Visual Studio aren't part of Windows or macOS infrastructure.
- my123 6y ago
  gcc is part of the infrastructure, for the simple reason that you need the same compiler version to build Linux kernel modules.

sergeykish 6y ago

The more I use linux (12 years), the more I believe that common users should not use "stable distribution". Upgrade is risky, software is always outdated. It solves nothing and provides unjustified feeling of stability. LTS makes sense as deployment platform. Push it to server and deploy own application. Make a demo like subject NVIDIA Jetson Nano SDK and forget about it. There are better ways to help underpowered machines - use light desktop environment, block ads in browser, add RAM if possible. Kernel and base requirements has not changed much in a decade. About 120 MB with XOrg.

rektide 6y ago
this feels like mass cowardice to me. run Debian testing or unstable. run something semi modern. not old lame vendor LTS. those who cower in LTS land, thinking they are saving themselves from troubles have very very very little experience, scant little too contribute to the community that cares & tries to remain mildly up to date. there is such a prevalent fear based mentality about running decent reasonable modern upstream software but it is such FUD, such a cannot do attitude. rarely can these camps justify their afraid behavior. LTS is nonsense. testing, unstable, they work well, & they expose real honest levels of support for systems, versus relying on antiquated but known support that LTS brings the tepid adopters.
- sergeykish 6y ago
  It is in the name, marketing, people use Debian Stable, Ubuntu Long Term Support, they don't use Ubuntu Outdated. But that's what it is. The moment it moves to Stable it does not receive versions update. We can't force rename. Maybe we can come up with better names for "testing", "unstable"? * Fresh * Upstream * Rolling I understand people don't want to switch distribution, channels out of fear, inconvenience. Can cross-platform package manager help? The one with dependency resolution — Nix, not the one that bundles it all together like Flatpak or Snap.

rektide 6y ago

this is godforsaken mother-of-all-anti-pattern sinful words. how terrible! don't trust the distro, don't trust upstream! trust only the particular bizarre awkward vendor tool chain? gods no. heavens no. the only reason, the only places this advice is ok is when your hardware is unsupportable, un-un-streamable, when the hardware embodies an anti-supportable form of existence. @jcelerier's advice here could not be more antithetical to the real story. if you need custom weirdo toolchains, something has gone direly wrong.