I wouldn't trust pip to install anything into my system. It's not a reliable program that I'd recommend anyone to use for things that they might depend on.
My typical course of action is to create a virtual environment for the package I need. Install the package into that virtual environment using pip or w/e the package wants to be installed with. Investigate and refine the dependencies I need (It's very common in the Python world to incorrectly specify dependencies, to require a lot of unnecessary dependencies, to depend on packages in the wrong way). And after I've figured out what exactly I need to get the package to work, copy the dependencies together with the package to the platlib directory of Python I'm using for this task. If platlib happens to be in the system directories or anywhere else: I wouldn't care about that. In the process of installing the program, I would've learned about the nature and the layout of dependencies, so that I could make informed decisions about what goes where and whether anything is needed or is in danger of being affected by system updates or endangers system updates. So far, this has worked every time. This worked for me personally, for small companies that do internal deployments and for big companies that distribute Python together with the entire Linux distribution in this way. The key ingredient is to know what you are doing and to be able to anticipate the bad things. Tools like pip take away from the users the need to know what they are doing in hopes of reducing complexity on the part of the users' knowledge necessary to accomplish program installation. However, there's no free lunch, and tools like pip bring an extra layer of complexity in trying to do what they claim. This layer of complexity is usually revealed when these tools fail to do what they claim, and users are forced to learn what they actually need to know and, on top of that, how to troubleshoot programs like pip. From working in infra / automation, I get the knowledge about program / package installation "free" on the job, so, I don't see a point in using a tool that automates that for me beyond what I already described. I'm probably also biased because of that, but I still think that learning to do the thing is more important than learning how to use the tool that does the thing. On Tue, Jan 14, 2025 at 4:42 PM Chris Green via Python-list <python-list@python.org> 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? > > 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. > > 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. > > Anything else? As far as I can see using pipx doesn't help me at > all (see recent thread here). > > -- > Chris Green > · > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
