Implement protections for externally managed Python environments (PEP 668)

[pradyunsg]

What's the problem this feature will solve?

See https://peps.python.org/pep-0668/#motivation for the details.

Describe the solution you'd like

Implement the protections, as described in https://peps.python.org/pep-0668/#specification

Alternative Solutions

N/A

Additional context

See https://peps.python.org/pep-0668/. If there's broader issues here, add to the discussion on https://discuss.python.org/t/10302/

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[astrojuanlu]

Does this mean that, say, pip won't try to touch conda or apt installed packages? Or are there more changes needed in apt and conda?

[pfmoore]

It means that conda and apt can configure the system environment to tell pip not to touch it. See the linked PEP for details, but basically:

1. It's at the level of environment, not package. If conda says their environment's site-packages is externally managed, you won't be able to use pip to install anything there.
2. The system integrator needs to opt into it.

[pradyunsg]

conda/conda#12245 is relevant.

[jezdez]

Edit: moved my comment about conda to the issue @pradyunsg created there.

[hroncok]

Would it make sense to move this discussion to the discussion page for the PEP itself rather than this implementation issue in pip?

[pradyunsg]

I think it would. :)

[stefanor]

Thank you for implementing this. The implementation seems to do the right thing in my testing :)

I assume this will break people's workflows, and so they'll delete the EXTERNALLY-MANAGED files. But at least they know what they're getting into.

And we can drop our most invasive pip patch in Debian, once this is released :)

The next Python upload to Debian unstable will declare this.
But I suspect we won't manage to ship a pip that supports it in time for the next Debian stable release. So, only early-adopters who install their own pip will see it, initially.