SABnzbd update script - python package conflict (EXTERNALLY-MANAGED) #745

Closed
opened 2026-02-04 21:12:40 +03:00 by OVERLORD · 6 comments
Owner

Originally created by @LaurenceBarnes on GitHub (Apr 4, 2025).

Have you read and understood the above guidelines?

yes

📜 What is the name of the script you are using?

SABnzbd LXC

📂 What was the exact command used to execute the script?

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/sabnzbd.sh)"

📝 Provide a clear and concise description of the issue.

Hi,

while trying to run the update script in the LXC shell, I encountered the classic error also encountered in https://github.com/community-scripts/ProxmoxVE/discussions/2675#discussioncomment-12338886 or https://github.com/community-scripts/ProxmoxVE/issues/1273. Because this is spread around through many separate issues and discussions, I thought that it might be better to raise this as a new issue.

I do get that one can remove or rename the EXTERNALLY-MANAGED file, but as mentioned in several places, this is just bad practice, as written in https://stackoverflow.com/questions/76082216/python-pip-error-externally-managed-environment-after-upgrading-to-ubuntu-23-0#comment139585599_76953030

I also did see https://github.com/community-scripts/ProxmoxVE/discussions/555 and check https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/misc/update-lxcs.sh which does that, even the installation script https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/sabnzbd-install.sh does it, but wouldn't it be better for the script to work with virtual environments as intended by the OS and python itself?

Also see https://packaging.python.org/en/latest/specifications/externally-managed-environments/ for reference

Attempting to use conventional Python packaging tools to manipulate such environments can be confusing at best and outright break the entire underlying operating system at worst. Documentation and interoperability guides only go so far in resolving such problems.

Of course please correct me if I am wrong, but I did work through my fair share of pain with virtual environments such as pipx because of this EXTERNALLY-MANAGED topic and it seems to be better to use e.g. pipx instead, or make sure that the OS package manager is always used to install systemwide packages if applicable.

This solution could be implemented into the scripts that use python packages instead of the current method:

https://stackoverflow.com/a/75722775

⚙️ What settings are you using?

  • Default Settings
  • Advanced Settings

🖥️ Which Linux distribution are you using?

Debian 12

🔄 Steps to reproduce the issue.

Use the script in the shell to update the LXC (verbose mode)

Paste the full error output (if available).

⠏ Updating SABnzbd to 4.5.0error: 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.
⠋ Updating SABnzbd to 4.5.0
[ERROR] in line 38: exit code 0: while executing command $STD python3 -m pip install -r requirements.txt

🖼️ Additional context (optional).

No response

Originally created by @LaurenceBarnes on GitHub (Apr 4, 2025). ### ✅ Have you read and understood the above guidelines? yes ### 📜 What is the name of the script you are using? SABnzbd LXC ### 📂 What was the exact command used to execute the script? `bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/sabnzbd.sh)"` ### 📝 Provide a clear and concise description of the issue. Hi, while trying to run the update script in the LXC shell, I encountered the classic error also encountered in https://github.com/community-scripts/ProxmoxVE/discussions/2675#discussioncomment-12338886 or https://github.com/community-scripts/ProxmoxVE/issues/1273. Because this is spread around through many separate issues and discussions, I thought that it might be better to raise this as a new issue. I do get that one can remove or rename the EXTERNALLY-MANAGED file, but as mentioned in several places, this is just bad practice, as written in https://stackoverflow.com/questions/76082216/python-pip-error-externally-managed-environment-after-upgrading-to-ubuntu-23-0#comment139585599_76953030 I also did see https://github.com/community-scripts/ProxmoxVE/discussions/555 and check https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/misc/update-lxcs.sh which does that, even the installation script https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/sabnzbd-install.sh does it, but wouldn't it be better for the script to work with virtual environments as intended by the OS and python itself? Also see https://packaging.python.org/en/latest/specifications/externally-managed-environments/ for reference > Attempting to use conventional Python packaging tools to manipulate such environments can be confusing at best and outright break the entire underlying operating system at worst. Documentation and interoperability guides only go so far in resolving such problems. Of course please correct me if I am wrong, but I did work through my fair share of pain with virtual environments such as pipx because of this EXTERNALLY-MANAGED topic and it seems to be better to use e.g. pipx instead, or make sure that the OS package manager is always used to install systemwide packages if applicable. This solution could be implemented into the scripts that use python packages instead of the current method: https://stackoverflow.com/a/75722775 ### ⚙️ What settings are you using? - [x] Default Settings - [ ] Advanced Settings ### 🖥️ Which Linux distribution are you using? Debian 12 ### 🔄 Steps to reproduce the issue. Use the script in the shell to update the LXC (verbose mode) ### ❌ Paste the full error output (if available). ``` ⠏ Updating SABnzbd to 4.5.0error: 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. ⠋ Updating SABnzbd to 4.5.0 [ERROR] in line 38: exit code 0: while executing command $STD python3 -m pip install -r requirements.txt ``` ### 🖼️ Additional context (optional). _No response_
OVERLORD added the bug label 2026-02-04 21:12:40 +03:00
Author
Owner

@MickLesk commented on GitHub (Apr 4, 2025):

https://github.com/community-scripts/ProxmoxVE/discussions/555

@MickLesk commented on GitHub (Apr 4, 2025): https://github.com/community-scripts/ProxmoxVE/discussions/555
Author
Owner

@LaurenceBarnes commented on GitHub (Apr 4, 2025):

@MickLesk I'd kindly ask you to read through the text - this solution is generally considered bad practice. "EXTERNALLY-MANAGED" should not be removed.

@LaurenceBarnes commented on GitHub (Apr 4, 2025): @MickLesk I'd kindly ask you to read through the text - this solution is generally considered bad practice. "EXTERNALLY-MANAGED" should not be removed.
Author
Owner

@MickLesk commented on GitHub (Apr 4, 2025):

Then feel free to open a PR that fixes it with your hoped-for solution. Then it is not a bug, but possibly a feature request. Our priorities are currently in the core, so nothing will come from us in the next few months. So feel free to do a PR.

@MickLesk commented on GitHub (Apr 4, 2025): Then feel free to open a PR that fixes it with your hoped-for solution. Then it is not a bug, but possibly a feature request. Our priorities are currently in the core, so nothing will come from us in the next few months. So feel free to do a PR.
Author
Owner

@tremor021 commented on GitHub (Apr 4, 2025):

Or give examples where removing EXTERNALY-MANAGED caused issues so we can look at it

@tremor021 commented on GitHub (Apr 4, 2025): Or give examples where removing EXTERNALY-MANAGED caused issues so we can look at it
Author
Owner

@LaurenceBarnes commented on GitHub (Apr 4, 2025):

Hi, thank you for the clarification. I agree with your point, you do have other priorities. I was just a little confused about the rejection when I already did the research and even linked the very same thread/discussion that you referred to as well. I want to help whereever I can, and I reported this issue since I learned about it not too long ago.

For now, I could raise this as a feature request issue if that makes sense from your point. There is not an extreme urgency, I am not aware of reports where it actually breaks things yet - ultimately people should have backups anyways - but it would be nice to follow the advice that I linked (https://stackoverflow.com/a/75722775). I am not knowledgable enough in scripts to PR that myself yet, as I am still learning to understand the matter, but I'd consider it if I get around to experimenting for some practical experience.

@LaurenceBarnes commented on GitHub (Apr 4, 2025): Hi, thank you for the clarification. I agree with your point, you do have other priorities. I was just a little confused about the rejection when I already did the research and even linked the very same thread/discussion that you referred to as well. I want to help whereever I can, and I reported this issue since I learned about it not too long ago. For now, I could raise this as a feature request issue if that makes sense from your point. There is not an extreme urgency, I am not aware of reports where it actually breaks things yet - ultimately people should have backups anyways - but it would be nice to follow the advice that I linked (https://stackoverflow.com/a/75722775). I am not knowledgable enough in scripts to PR that myself yet, as I am still learning to understand the matter, but I'd consider it if I get around to experimenting for some practical experience.
Author
Owner

@LaurenceBarnes commented on GitHub (Apr 4, 2025):

Or give examples where removing EXTERNALY-MANAGED caused issues so we can look at it

The problem is that modifying system-wide python installs with pip instead of the system package manager can subtly break things in the system in ways that are noticed much later. As far as I understood, this is because pip and apt do not communicate about modifications.

There likely is a good reason why debian blocks system wide pip installs and instead insists on pipx or venv.

@LaurenceBarnes commented on GitHub (Apr 4, 2025): > Or give examples where removing EXTERNALY-MANAGED caused issues so we can look at it The problem is that modifying system-wide python installs with pip instead of the system package manager can subtly break things in the system in ways that are noticed much later. As far as I understood, this is because pip and apt do not communicate about modifications. There likely is a good reason why debian blocks system wide pip installs and instead insists on pipx or venv.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ProxmoxVE#745