Attached some archive discussion by Kian-Tat Lim referred on Slack for reference. So what about checking for the python version? If the installation's python version is  >=3.2 chmodding can be safely ignored by the installer as any accidentally generated, non-versioned older *.pyc won't be picked up, can't be ?

From Slack:

Gabor Kovacs [Oct 12th at 11:34 AM]
Gabor Kovacs
Is there a particular reason why the "python" subdir in an eups installation (by lsstsw) is not owner writeable?

```rw-rw-r- 1 gkovacs gkovacs 4202 Oct 9 17:02 Makefile
dr-xr-xr-x 3 gkovacs gkovacs 4096 Oct 9 17:02 python```
Show more…
Thread in #generalOct 12th at 11:06 AM

3 replies
Paul Price [3 days ago]
Yes. It was originally done to prevent the python being recompiled on system with a different system python than the one in the distribution. I don’t remember the details.

Paul Price [3 days ago]
https://github.com/RobertLuptonTheGood/eups/commit/28656311d332805848b79ba5ed872521eac35b49

Robert Lupton [3 days ago]
I.e. it's not intrinsic to eups, it's a workaround for the way that python behaves. If someone can propose a better workaround I'd be happy to support it!

Gabor Kovacs [Oct 12th at 2:14 PM]
So is the problem only the concurrent rewriting by different cpython interpreter versions or just concurrent rewriting in general even by the same version ? What about PEP-3147 ?

3 replies
Paul Price [3 days ago]
Implemented in Python 3.2, but we were having trouble with 2.6 and 2.7.

Paul Price [3 days ago]
And eups, I believe, continues to support python >= 2.5 .

Robert Lupton [2 days ago]
I think we could bump it to 2.7, but we could only do the explicit `chmod` for py3

We know at install time what python version is being used for the install, but we don't know what python versions might be used in the future.

That said, I agree this is annoying, and so maybe we should make this feature an option, rather than lumping everyone with the solution for a problem they likely don't have?

Is this specifically an eups issue or was it a permissions issue from lsstsw installing miniconda? lsstsw no longer installs eups itself since it is now part of the conda-forge installation. Does that fix the problem for our users?

I'm honestly not sure if anything has changed and haven't looked at this in the context of conda. But, FWIW, I always ran into this in the context of newinstall.sh.

This was an issue with installing eups via its own installation process. Installing it via conda, as we do now, means that it isn't a problem, as conda pregenerates all .pyc files