Installation guide doesn't work on Raspberry Pi OS based on Bookworm

[eslindsey]

Describe the bug

Latest version of Raspberry Pi OS blocks sudo pip install and wants to use venv.

To Reproduce

Attempt to follow the PILOT Drive installation guide on latest Raspberry Pi OS.

Expected behavior

Successful installation.

Actual behavior

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.

    For more information visit http://rptl.io/venv

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.

Host information:

• OS: Raspberry Pi OS (64-bit)
• Version: A port of Debian Bookworm with the Raspberry Pi Desktop

Additional context

I did get this working in a venv, but I think that's going to be a huge (and unnecessary) pain on a system that is dedicated only to PILOT Drive. I had thought that there was no way to force an install, because I had not read the last sentence of the note until I was typing it.

Perhaps that means this is just a documentation update, but I'll have to wait until I get home from work to try out "breaking system packages" and report back. :)

[lamemakes]

Latest version of Raspberry Pi OS blocks sudo pip install and wants to use venv

As it should! sudo pip really shouldn't be used but this was my hack-ier soltuion that hasn't had time for a solid revisit.

I did get this working in a venv

I'd love to hear what you did! From what I remember utilizing escalated privileges may only be required for a few select areas so if that could be isolated to the bare minimum I'd be happy to implement it into the code base.

Thanks for opening this issue! I haven't the capacity I'd like to put work into PILOT Drive but would like to at least keep it up to date with the latest & greatest.

[eslindsey]

I should have specified that the only way I got it working in the venv was to create the venv as root.

--break-system-packages works fine to restore your hacki-ness, but the setup script still crashes for the same reason as the issue: it attempts to call pip3 install without --break-system-packages.

Regarding keeping root restricted, that's a good security practice but with a product like this designed to (potentially) interact with so much hardware, is it feasible? Last I checked the Raspberry Pi GPIO is massively more efficient when it can memory map the hardware registers on the BCM directly, which can only be done as root. That's just one example off the top of my head. I suppose USB and Bluetooth can both be accessed from userland, so OBD2 and radio tuners etc. wouldn't be an issue. Web server already defaults to a non-privileged port, so no problems there.