Strategies for avoiding having to use --break-system-packages with pip
Thomas Passin
list1 at tompassin.net
Tue Jan 14 11:36:34 EST 2025
On 1/14/2025 6:32 AM, Chris Green via Python-list wrote:
> I have a (relatively) clean Debian 12 installation running on my two
> workhorse systems, a desktop server at home and my laptop that travels
> around with me.
>
> I moved from Xubuntu to Debian on both these systems a few months ago.
>
> I ran Xubuntu for many years and acquired a whole lot of python
> packages installed with pip, as root. For the last couple of years I
> had to use the --break-system-packages option to get things installed.
>
> As far as I'm aware I never hit any dependency problems doing this.
> It's probably because things I installed with pip were mostly quite
> small, specialised, packages that I used in just one or two utility
> programs that I had written myself. In quite a few cases these were
> realated to image processing and such things.
>
>
> So far I've managed to keep my Debian 12 installations 'pip free', I
> haven't even got pip installed. However I may have just come across
> something that would at least be very useful and it comes from PyPi.
> (It's tkintertable if that's of any interest or relevance)
>
>
> What are my options?
>
> Just install it using pip as root and --break-system-packages,
> what's likely to break?
You can also install with --user and --break-system-packages, but that
doesn't really solve the problem. Also, as just happened to me, if an
upgrade happens to change the system's python to a newer version (e.g.,
3.12.x to 3.13.y), you would have to install all your packages again
with the new Python install.
> Use a virtual environment, what do I have to do then to make using
> my program (that uses tkintertable) 'transparent', i.e. I just
> want to be able to run the program from the command prompt like
> any other program.
You can write a shell script that activates the venv and then launches
your program. This works pretty well.
> Download tkintertable from git into my development environment and
> use that. My PYTHONPATH will need to point to it but I can't see
> any further issues with doing this.
This is an approach I use sometimes, mainly if I have cloned a project.
I run the project's program(s) using a script that sets the PYTHONPATH.
> Anything else? As far as I can see using pipx doesn't help me at
> all (see recent thread here).
To completely avoid problems when the system's Python install gets
changed, you can install your own Python version outside of the package
manager; it doesn't have to be the same version as the system's. I've
done this when I wanted to run a later version of Python than the
system's. You would have to take care of updating it yourself since the
package manager won't know about it. On the system where I did this, I
ran the system's python version using "python3" and my own using
"python3.11" (I think the system was still on 3.8 or 3.9).
More information about the Python-list
mailing list