Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Why does Pip display "error: externally-managed-environment", and what can I do about it?

Parent

Why does Pip display "error: externally-managed-environment", and what can I do about it?

+3
−0

My (non-Windows) operating system came with Python, but that Python didn't include Pip. I followed instructions to install Pip for the included Python, using my system's package manager.

But now when I try to use Pip, I[1] get errors like:

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.

What's going on here? What does it mean by "externally managed", and why should I have to jump through the hoops described?


  1. In reality, my system doesn't actually work this way - and I haven't actually installed Pip for my system Python, because I personally recommend against doing so. The error message shown here is copied from the corresponding Stack Overflow question (alternately). ↩︎

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+0
−0

tl;dr: There's a few ways to bypass this:

  • For all users on the machine: Get rid of /usr/lib/python3.foo/EXTERNALLY-MANAGED. To prevent your package manager from adding it back, replace it with a dummy/empty file. (you'll have to do this again for every minor Python version)
  • For your user only: Create or edit ~/.config/pip/pip.conf so that it contains:
    [global]
    break-system-packages = true
    
  • For one shell session: Set the environment variable PIP_BREAK_SYSTEM_PACKAGES=1 (you can configure your shell to always set this)
  • For one command only: Pass --break-system-packages to pip.

(there used to be some thoughts here on why this has become necessary in recent years, but it proved controversial and I removed it)

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

Misattributed blame (4 comments)
Misattributed blame
Karl Knechtel‭ wrote 5 months ago · edited 5 months ago

The rhetoric in this answer makes it hard to take seriously. It seems fairly clear that it's primarily the distro maintainers who want the system package manager to be used for the system Python; and the idea is motivated by known potential harms, not devs' aesthetics or morality.

PEP 668 lays out concrete reasons why arbitrary use of Pip on the system Python - whether directly in /usr or with a user-level install - could interfere with the intended operation of the system Python. (It could even break the system package manager, which might itself involve a wrapper written in Python.) PEP 668 arose out of concerns raised by those distro maintainers.

I assume your goal is simply to offer a shorter, more direct answer, but I don't think this really fits the bill.

matthewsnyder‭ wrote 5 months ago

I often search for this again and again, because I forget some details of the process like the exact path of the file. I've become frustrated with a pattern where I find answers on StackOverflow and elsewhere, that force me to scroll past a disclaimer (with which I am already familiar) on why I shouldn't do it, before I can find the part on how to do it. I decided to post this answer for people like me, who are not looking for the extended discussion.

I thought it would be less confusing if I addressed the obvious "why do I have to jump through these hoops?". But I'm not really interested in debating the why here, so I took it out.

Karl Knechtel‭ wrote 5 months ago

... wait, really? Because whenever I look at Stack Overflow, I see tons of people suggesting the devil-may-come workaround, and the answer with a proper disclaimer gets buried. There was literally a thread just today on the official Python Discourse forum complaining about this effect on this specific topic, even.

(Also, I don't really understand the complaint about repeated search. If you're using the --break-system-packages approach, the error literally reminds you how it works. If you're removing or renaming the marker file, why would you have to do it more than once?)

matthewsnyder‭ wrote 5 months ago

Sounds like we should just swap places and we'd both be perfectly happy...