3 ms·

> Want python later than 3.6? apt-get install python3.7 or apt-get install python3.8

amelius 6y ago
That might theoretically trigger updates of packages on which NVidia stuff depends (through indirection), which will then render your system unusable. You might be lucky, though.
- speedgoose 6y ago
  An alternative is to use Docker containers or similar.
- stjohnswarts 6y ago
  that's why you look at what's getting install before you hit go. anyway it's easy enough to backup and restore almost all these SBC's
- andrewf 6y ago
  I think it'll be all right. python3.8 is its own distinct package, which will install alongside the existing python3.6. Debian/Ubuntu's "alternatives" system can select what /usr/bin/python3 runs. In practice, changing that away from the distribution default can break other people's code, and the win of an LTS is not spending time on that stuff. But you can get yourself a Python 3.8, then you can build venvs, run a Jupyter kernel in it, whatever you like. If you can download or rebuild all the modules you want in a 3.8 venv, you're pretty set. And everything wanting Python 3.6 on your LTS still works.
janoc 6y ago
That will most likely break OpenCV, Tensorflow and CUDA which depend on binary packages compiled for the given version of Python.
- freeone3000 6y ago
  CUDA doesn't depend on python, it's the other way around. And you'd install the new versions of those packages.
  - janoc 6y ago
    What I meant is that it would break the CUDA package for Python and support in things like Tensorflow, obviously. Not CUDA itself. You can't just "install new version" of those packages unless Nvidia supports it, unless Tensorflow supports it, unless OpenCV works with it. If you have ever tried to build Tensorflow from source, you would know what I am talking about.
    - freeone3000 6y ago
      I have, on python 3.7, and it works fine with the entire CUDA matrix from 10.1 to 11. So your point has theoretical merit, but in practice, it's not a real problem as compatible versions of those packages are readily available.

That might theoretically trigger updates of packages on which NVidia stuff depends (through indirection), which will then render your system unusable. You might be lucky, though.

speedgoose 6y ago
An alternative is to use Docker containers or similar.
stjohnswarts 6y ago
that's why you look at what's getting install before you hit go. anyway it's easy enough to backup and restore almost all these SBC's
andrewf 6y ago
I think it'll be all right. python3.8 is its own distinct package, which will install alongside the existing python3.6. Debian/Ubuntu's "alternatives" system can select what /usr/bin/python3 runs. In practice, changing that away from the distribution default can break other people's code, and the win of an LTS is not spending time on that stuff. But you can get yourself a Python 3.8, then you can build venvs, run a Jupyter kernel in it, whatever you like. If you can download or rebuild all the modules you want in a 3.8 venv, you're pretty set. And everything wanting Python 3.6 on your LTS still works.

janoc 6y ago

That will most likely break OpenCV, Tensorflow and CUDA which depend on binary packages compiled for the given version of Python.

freeone3000 6y ago
CUDA doesn't depend on python, it's the other way around. And you'd install the new versions of those packages.
- janoc 6y ago
  What I meant is that it would break the CUDA package for Python and support in things like Tensorflow, obviously. Not CUDA itself. You can't just "install new version" of those packages unless Nvidia supports it, unless Tensorflow supports it, unless OpenCV works with it. If you have ever tried to build Tensorflow from source, you would know what I am talking about.
  - freeone3000 6y ago
    I have, on python 3.7, and it works fine with the entire CUDA matrix from 10.1 to 11. So your point has theoretical merit, but in practice, it's not a real problem as compatible versions of those packages are readily available.