Python PEP 668

[0x6d6f7468]

OS Used - ALL Information (architecture, linux flavor, etc.)

OS: Parrot Security
Architecture: aarch64
Python version: 3.11.2

Pastebin link to error you are encountering

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.

Expected behavior (vs. what you encountered)

Install Python packages

Any additional information

Starting in Python 3.11, PEP 668 will prevent pip from installing system packages if the wider environment is managed by the package manager. There seems to be a few possible solutions for this:

1. Break system packages via either export PIP_BREAK_SYSTEM_PACKAGES=1 or --break-system-packages argument
2. Install all packages with local package manager (making sure we have Selenium 4.9.1)
3. Look into installing everything into a virtual environment

I'm playing with this in my current setup.sh work. My current solution has been to just break system packages because I do all of my work in a transient VM, but I'm uncomfortable with this being the de facto solution without other people weighing in first. I'll look into the other solutions in the meantime, as time allows.

[digininja]

I'm not a python user, but isn't this what venv is for?

…

On Tue, 9 Jan 2024, 22:41 moth, ***@***.***> wrote: OS Used - ALL Information (architecture, linux flavor, etc.) OS: Parrot Security Architecture: aarch64 Python version: 3.11.2 Pastebin link to error you are encountering 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. Expected behavior (vs. what you encountered) Install Python packages Any additional information Starting in Python 3.11, PEP 668 will prevent pip from installing system packages if the wider environment is managed by the package manager. There seems to be a few possible solutions for this: 1. Break system packages via either export PIP_BREAK_SYSTEM_PACKAGES=1 or --break-system-packages argument 2. Install all packages with local package manager (making sure we have Selenium 4.9.1) 3. Look into installing everything into a virtual environment I'm playing with this in my current setup.sh work. My current solution has been to just break system packages because I do all of my work in a transient VM, but I'm uncomfortable with this being the de facto solution without other people weighing in first. I'll look into the other solutions. — Reply to this email directly, view it on GitHub <#636>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4SWNIQRD4FQBLNPNUQULYNXBSRAVCNFSM6AAAAABBT25BNKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3TGMRYG42DIMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[0x6d6f7468]

Yes, that is my understanding. I'm hoping that we might be able to switch to that without too much hassle (or change in usage).

[digininja]

Just watch out for Kali vs Ubuntu, we had to switch to doing system packages in Kali for a reason a while ago, I can't remember why but I documented it all in a ticket when I finally worked out what was causing the problem. Ubuntu still seems happy to use pip packages.

…

On Tue, 9 Jan 2024 at 22:50, moth ***@***.***> wrote: Yes, that is my understanding. I'm hoping that we might be able to switch to that without too much hassle (or change in usage). — Reply to this email directly, view it on GitHub <#636 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4SWJ7OWZIONA7QTPFRS3YNXCS5AVCNFSM6AAAAABBT25BNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTHEZDGMBSGE> . You are receiving this because you commented.Message ID: ***@***.***>

[0x6d6f7468]

I believe Ubuntu is still on Python 3.10 at the time of writing.

If you end up remembering any more information about that ticket you mention, that'd be helpful. However, it seems pretty obvious that we're going to want to switch to venvs.