DietPi-Software | Add LazyLibrarian

[JappeHallunken]

There was a request for LazyLibrarian since Readarrr will not be maintained anymore, see https://dietpi.com/forum/t/readarr-has-been-retired-what-about-lazylibrarian-instead/24105/6

I chose to use python venv and install python3-venv and place the environment in the data folder /mnt/dietpi_userdata/lazylibrarian/env.
So in the end we can just remove the whole home folder for uninstall and get rid of everything (except for the package python3-venv).
I dunno it this is the way you like to go, since no other dietpi app uses python3-venv as far as I can tell.
But maybe it's a good idea to seperate different python apps in the future anyways, so maybe you could make it a default dependency for python installations?

I also chose at some point to use G_EXEC_OUTPUT=1 for the pip installation command.
With the default behaviour (just to use G_EXEC) the user could get the impression the installation is stuck, because it takes a while even on my RPi 3.

I tested this on:
RPi 3 Model B (aarch64)
DietPi v9.17.2 (dev)
Debian 13.1 (trixie)
Linux TestPi3B 6.12.47+rpt-rpi-v8

[MichaIng]

Thank you very much!

Yes I think it is good to consequently use venv from now on, as well for other Python software options when touching them anyway. The break-system-packages=true worked until now, but there are further issues in the meantime when pip tries and fails to uninstall a Python module installed via APT. Previously, that was ignored (/usr/lib/python3 vs /usr/local/lib/python3 site), but recent pip chokes on it.

I also use G_EXEC_OUTPUT=1 for all pip and npm and alike installations. They can take long, and the output is not trivial.

I just invited you as collaborator, wondered this was not the case yet. So you can trigger installation tests: https://github.com/MichaIng/DietPi/actions/workflows/dietpi-software.yml

I just triggered them, but currently the pipeline is blocked by image builds: https://github.com/MichaIng/DietPi/actions/runs/17899904481