How does a competent System Manager track ALL the Python packages their users install?

It recently became painfully obvious that I just don't know how I'm supposed to manage Python packages on my systems.

I simply MUST be able to know what all is installed and under what user IDs, since the Python community is coached that nothing should be installed as Root. . . . This leaves me with a serious problem!

In this instance, I'm using Fedora distributions, MOSTLY but not exclusively Fedora Server (all some form of Fedora Core) BUT, the question applies for other distributions, too, I'm sure.

Ultimately, the question is; how is a system manager supposed to deal with this PROPERLY?

Do note that I'm NOT asking about how to install Python itself, and I'm not talking about a development system, where if the developers screw up their own system, well, it only affects THEM, though that's still not great.

What I'm focused on is that SOME packages of software that use Python have their own sub-packages that aren't available via the usual platform package installation paradigm. And it was one of these that prompted this sudden discovery of the risk I have; Mailman3 is just such a package as installing it didn't also install all the needed sub-packages, so there were then some "pip install"s needed for those. And on discussing it with a colleague, he admitted screwing up a system that I am responsible for managing, only to learn he screwed it up via a Python package he pip installed...

...I feel like I may be forced to implement security so individual users CANNOT install Python packages and thus increase my own workload, not only to do that, but then to install packages they want FOR them and all the hassles that entails. I'm hoping I'm just clueless about some "feature" of Python! Otherwise, I think Python needs a serious re-think about how it does what it does as it surely appears to be very unfriendly for the system manager(s).

Your developers should use Python Virtual Environments for the applications. With these virtual environments, that applications' dependencies are installed in that particular environment, and they don't affect other environments.

When application is developed and tested in the virtual environment, then it is verified that all dependencies are installed correctly.

If some package is missing dependencies, then you need to notify the package maintainer to update dependencies.

Someone can be in charge of automating the install of needed applications, and ensuring they work. Possibly providing VMs or containers with applications pre installed. Up to your organization whether they are considered more of an ops person or a developer person.

OS administrators who favor the system package manager might wrap every package in rpm or deb. Unifies install of in this case Mailman 3 all the way to back to its python dependencies. Packages can be signed and delivered with the same infrastructure that applies OS updates. However, requires significant packaging work, for the thing and its dependencies. Looks like Fedora has a mailman3 package and their infrastructure uses it.

Developers and other users might abandon the system package manger in favor of a language specific one, in this case Python pip. Gains access to the latest versions of a vast number of packages, and can install them in a unprivileged user's directory. However, the administrator has less control, and users might get themselves into trouble. Probably they will get into trouble as Mailman 3 dependencies has C libraries to link to, MTA setup, and a database, and a separate web UI application.

Conflicts you observed between the system packages and pip hint you need to pick one. Either package it in a way compatible with the system python, or it put in a virtualenv containing requirements. While you might remove the pip package to prevent users from messing with things, pip can be bootstrapped by a determined user. Ideally, help people install a set of known working applications.