[BUG] - lidarr - error: externally-managed-environment about arr-scripts HOT 6 CLOSED

Looks like your suggestion fixed it!

Thanks for the bug report!

When I leave it on autopilot for so long, don't always notice when there is a problem....

Edit: @Icenova20 Please verify and close this issue!

from arr-scripts.

FYI, I have just started seeing this same behavior in a recently updated radarr container. If the decided fix is to add the --break-system-packages flag to the lidarr setup.bash script, you may also want to propagate that to the other setup scripts.

from arr-scripts.

Just to add some context:

PEP668 was introduced for Python 3.11 to try to prevent conflicts between system installed packages and user installed packages. The solution above is removing a cover before hitting the big red button so to speak. The intended way to use pip going forward is to create a venv (vitual env.) for all user isntalled packages to sit in, and force python to run within the venv.

@RandomNinjaAtk I don't think this will be an issue for new installs since your script installs python and pip at the latest versions, however there could potentially be issues for existing users running an older version of pip. If they try to reinstall with setup.bash, the bash file will try to install pip, and pass over it since its already installed, and cause an issue since --break-system-packages won't be a valid flag. Can you force apk to force the install for pip? I think that would account for old installs.

from arr-scripts.

@hockeygoalie35

The packages are installed into the container... not host. So there shouldn't be any conflicts...?
Isn't that the entire point of using a container....?

from arr-scripts.

It's not host vs container, its python's included packages vs. user installed. There likely won't be conflicts for our use, but that doesn't stop pip from throwing that error. It's implemented in the latest versions of pip. The Lidarr image is still presumably based off a linux distro right? So calling apk get python3-dev will install python plus some global site packages (os, psutil, csv, etc). Then pip is used to install some non site-packages, that's where potential conflicts laid out in PEP 668 aims to fix. So if you're using the latest version of pip (24..?), adding this flag is no issue. But I see an issue in the potential case:

Lets say I spun up a container last year and install last years setup.bash, that grabs pip 23.1.2. Then today I decided something's not working right, and as a troubleshooting step, I delete the lidarr-extended folders and start over, without nuking the entire container, just stopping it (so the old version of python and pip remain). I run the latest setup.bash. When it gets to apk get py3-pip \ , apk will presumably find pip 23.1.2 installed and pass over that step. Then when setup.bash invokes pip install --upgrade --no-cache-dir --break-system-packages\, pip 23.1.2 has no --break-system-packages flag, and will throw an error and the install won't continue.

and @zybron is right, this change will need to be added to all setup scripts.

from arr-scripts.

It looks like the script is working.

does the same line need to be added here?

https://github.com/RandomNinjaAtk/arr-scripts/blob/92b9f3a1954e15603a481cf6ef1a0a459931c330/lidarr/setup.bash#L51C1-L53C51

I notice in the log I'm getting the same error, but it doesn't appear to be causing any harm at this location to my eyes.

from arr-scripts.