#123 - [BUG] - lidarr - error: externally-managed-environment - starred/arr-scripts

deekerman commented

2026-02-20 00:15:37 -05:00

Owner

Originally created by @Icenova20 on GitHub (Mar 21, 2024).

Originally assigned to: @RandomNinjaAtk on GitHub.

Setup.bash wont install python packages and gives below error

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

I believe this issue is because I run the container as root? My filesystem doesn't support linux permissions so i had to use root at a work around (i think)

github.com/RandomNinjaAtk/arr-scripts@92b9f3a195/lidarr/setup.bash (L27C1-L39C14)
solved by adding --break-system-packages to pip install

Originally created by @Icenova20 on GitHub (Mar 21, 2024). Originally assigned to: @RandomNinjaAtk on GitHub. Setup.bash wont install python packages and gives below error ``` error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification. ``` I believe this issue is because I run the container as root? My filesystem doesn't support linux permissions so i had to use root at a work around (i think) https://github.com/RandomNinjaAtk/arr-scripts/blob/92b9f3a1954e15603a481cf6ef1a0a459931c330/lidarr/setup.bash#L27C1-L39C14 solved by adding `--break-system-packages` to pip install

deekerman

2026-02-20 00:15:37 -05:00

closed this issue
added the
bug

lidarr

good first issue
labels

deekerman commented

2026-02-20 00:15:38 -05:00

Author

Owner

@RandomNinjaAtk commented on GitHub (Mar 21, 2024):

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!

@RandomNinjaAtk commented on GitHub (Mar 21, 2024): 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!

deekerman commented

2026-02-20 00:15:39 -05:00

Author

Owner

@hockeygoalie35 commented on GitHub (Mar 21, 2024):

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.

@hockeygoalie35 commented on GitHub (Mar 21, 2024): 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.

deekerman commented

2026-02-20 00:15:39 -05:00

Author

Owner

@RandomNinjaAtk commented on GitHub (Mar 21, 2024):

@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....?

@RandomNinjaAtk commented on GitHub (Mar 21, 2024): @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....?

deekerman commented

2026-02-20 00:15:40 -05:00

Author

Owner

@zybron commented on GitHub (Mar 21, 2024):

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.

@zybron commented on GitHub (Mar 21, 2024): 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.

deekerman commented

2026-02-20 00:15:41 -05:00

Author

Owner

@hockeygoalie35 commented on GitHub (Mar 21, 2024):

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.

@hockeygoalie35 commented on GitHub (Mar 21, 2024): 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.

deekerman commented

2026-02-20 00:15:41 -05:00

Author

Owner

@Icenova20 commented on GitHub (Mar 21, 2024):

It looks like the script is working.

does the same line need to be added here?

github.com/RandomNinjaAtk/arr-scripts@92b9f3a195/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.

@Icenova20 commented on GitHub (Mar 21, 2024): 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.

Rows
Columns

[BUG] - lidarr - error: externally-managed-environment #123