Pycache creation or inhibition, vary by install location

Python Help
1

I’m looking for a way to inhibit creation of .pyc files for modules installed in a particular location, while not inhibiting the creation of .pyc files for modules installed anywhere else. Is there a way to accomplish this?

Rationale/Details:

  • I’m in a networked environment with 1000s of users.
  • Network has multiple platforms, and requires support a “standard” set of python versions. So I have a set of python virtual environments supporting each combination of python version and platform.
  • We have a collection of Python-only modules that are intended to be used in all of these virtual environments
  • There are multiple maintainers for the module source, and deployment needs to be as simple as pushing the updated source files to a common network location. All virtual environments have a .pth file that extends sys.path to find these modules in this common network location.
  • Because of multiple maintainers, first person (user “A”) to do “import ecommlib” will trigger creation of .pyc files in the common network location, and will own the .pyc files as a result. Next person that pushes changes to ecommlib source will cause a problem for everyone except that first user, because new .pyc files will be needed, but only user “A” can overwrite those .pyc files.

So, I want to avoid creation .pyc files files these common/shared python-only modules, but I don’t want to use the “-B” sledgehammer, and inhibit .pyc creation globally, as that is not necessary, and I don’t want to impact anyone else’s performance with their own code.

Is there any way to accomplish this?

2

I’m surprised the shared Python-only modules aren’t read-only to the 1000s of users already, to prevent malicious tampering from only 0.01% of them bringing the entire organisation to a halt.

Is it problematic to tell the devs with write access not to import directly from it, as doing so will break prod?

The fundamental flaw here is the current architecture is completely dysfunctional, and has no principle of least privilege. Some kind of source repo for the devs, and package index for the users is needed. If they all install local copies from that, they should find it far harder, if not impossible to mess things up for the 999 others.

1 Like