Python upgrade

[Panzermann]

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:

Code: Select all

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

[WarHawk]

Do you do normal

Code: Select all

$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...

[johnvick]

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.

[MichaIng]

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.

[Panzermann]

Thanks for your input so far, chaps. Much appreciated.

I will give pyenv a whirl. The approach is appealing.

[MichaIng]

Jep, only downside of pyenv is the time cosuming Python compilation, on RPi Zero and similar easily more than an hour.

[Panzermann]

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.

[MichaIng]

@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:

Code: Select all

echo '#!/bin/dash
cd /path/to/script
export PATH="/path/to/script/.pyenv/bin:$PATH"
eval "$(pyenv init -)"' > /path/to/script/pyenv-activate.sh

Code: Select all

echo '#!/bin/dash
. /path/to/script/pyenv-activate.sh
command to start software' > /path/to/script/script_name-start.sh

Code: Select all

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.

[johnvick]

Docker is much easier

[MichaIng]

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.