Some scripts used to interface NZBGet and Medusa (nzbToSickBeard and nzbToMedia in particular) require Python > 3.5. This leads to the following error messages in NZBGet:
nzbToSickBeard: /mnt/dietpi_userdata/nzbget/scripts/nzbToMedia/eol.py:139: LifetimeWarning: Python 3.5 is no longer supported.
nzbToSickBeard: warnings.warn(msg, LifetimeWarning)
nzbToSickBeard: [20:09:28] [INFO]::MAIN: Python v3.5 will reach end of life in 236 days.
nzbToSickBeard: [20:09:29] [INFO]::MAIN: Auto-Updating nzbToMedia, Please wait ...
nzbToSickBeard: [20:09:31] [ERROR]::MAIN: Update failed, not restarting. Check your log for more information.
What would be the “DietPi” way of upgrading Python ?
Thanks so much for your help.
Best regards
Do you do normal
$sudo apt-get update
$sudo apt-get upgrade -y
updates often??
It still has 236 days before it goes kaput…so there may be a community upgrade before then…
One way round this is to use Docker to run these apps - well worth investing the time in learning how it works. Then no worries over Python versions. It’s available in dietpi-software but from then on you have to manually install what you want.
I hope that even Stretch gets a backport of newer Python3 versions before it reaches EOL. Yeah we simply install the packages from the Debian/Raspbian repo.
Again another alternative to container (docker,…) is pyenv, which allows to pull Python3.8 already.
Thanks for your input so far, chaps. Much appreciated.
I will give pyenv a whirl. The approach is appealing.
Jep, only downside of pyenv is the time cosuming Python compilation, on RPi Zero and similar easily more than an hour.
Just a quick follow-up question:
On DietPi, is ~/.bash_profile the right script to put pyenv’s environment variable definition and init commands ?
It seems right because I use DietPi via SSH, thus via a login session. However, ~/.bashrc contains loads of commands that are obviously executed as well, like aliases and shell colour definitions.
Just a bit confused which one to use.
Panzermann
Not sure if you want your login user (or root) to activate the pyenv environment and even if so, if you want to have the pyenv activated throughout all the shell session?
I would in every case create a script which contains pyenv activation and starts the software, this script can then be started via dietpi-postboot or systemd unit.
If this is a oneshot task, hence it does its job quickly and then exits, your could place the script into /var/lib/dietpi/postboot.d/, which will run at the end of boot by root user.
If you want to run it as unprivileged user and/or if it is a background service that stays active in background, create a systemd unit. Here an example how we do this with Home Assistant:
echo '#!/bin/dash
cd /path/to/script
export PATH="/path/to/script/.pyenv/bin:$PATH"
eval "$(pyenv init -)"' > /path/to/script/pyenv-activate.sh
echo '#!/bin/dash
. /path/to/script/pyenv-activate.sh
command to start software' > /path/to/script/script_name-start.sh
echo '[Unit]
Description=Script description
After=dietpi-postboot.service
[Service]
SyslogIdentifier=script_name
User=user_name
ExecStart=/path/to/script/script_name-start.sh
[Install]
WantedBy=multi-user.target' > /etc/systemd/system/script_name.service
systemctl daemon-reload
systemctl enable --now script_name
Replace /path/to/script user_name and script_name to your needs. After=dietpi-postboot.service is to have it running right when login prompts appear, hence after most boot tasks have finished.
But docker creates some overhead. But yeah further isolation from the system and easy updates and all of this, hence recommended at least if one uses docker already for other tasks.
Before I adpoted Docker I had to install different Python versions for different apps - and not all versions at the time were installable by apt-get so I had to complie one. Then I had to choose a system default and then edit each systemd startup script to select the required Python version for each app. I have since moved almost all my apps to Docker using Portainer to setup, and whilst it took a bit of learning it was well worth it.
For example Emby runs nicely, no need to manually update any more. I instaled Calibre-web manually - got it working - lots of tricky Python pip installs involved and it ran but never properly, and setting file permsssions was tricky. The docker version installed easily and runs perfectly. No downside as yet.
