4.2b1 overwrites Python's site.py?

Issue #504 closed
Skip Montanaro created an issue

(The last version I installed at work was 3.7. Not sure if this bug report is specific to 4.2b1 or anything newer than 3.7.)

I downloaded coverage 4.2b1 then packaged it up using our internal system (little more than a tar file of the install tree plus an info file.) I pushed that out, thinking that as a development tool, it would have no production impacts. Unfortunately, the install process created a site.py file (see the attached build.out file).

Python in this case is Python 2.7.2. That has been static/stable/outdated since before I first installed coverage locally, so I don't think my toolchain has changed in any meaningful way. I'm sort of guessing that the setup.py script which comes with Coverage has changed.

Why is the install process creating a site.py file? I think I can work around the problem by removing site.py and site.pyc from the /var/tmp/... install location before repackaging it, but some piece of the tool chain must have thought that creating it was a good idea. I'd kind of like to understand who was ultimately responsible for this.

Comments (8)

  1. Ned Batchelder repo owner

    @skip_montanaro I am not trying to create a site.py, and I'm not sure if other people are getting one created but not noticing. Can you share the contents of the site.py file?

  2. Skip Montanaro reporter

    Sure, here it is... (I suspect it's distutils or similar, but that whole part of the world is quite obscure to me.)

  3. Ned Batchelder repo owner

    When I install into a virtualenv, I don't see that happen. I have nothing between the "removing" line and the "processing" line:

    creating dist
    creating 'dist/coverage-4.2b1-py2.7-macosx-10.10-intel.egg' and adding 'build/bdist.macosx-10.10-intel/egg' to it
    removing 'build/bdist.macosx-10.10-intel/egg' (and everything under it)
    Processing coverage-4.2b1-py2.7-macosx-10.10-intel.egg
    creating /usr/local/virtualenvs/tmp-49d598383246fdb1/lib/python2.7/site-packages/coverage-4.2b1-py2.7-macosx-10.10-intel.egg
    Extracting coverage-4.2b1-py2.7-macosx-10.10-intel.egg to /usr/local/virtualenvs/tmp-49d598383246fdb1/lib/python2.7/site-packages
    Adding coverage 4.2b1 to easy-install.pth file

    When I use your style of install (with --prefix and an explicit PYTHONPATH), then it does create the site.py file.

    Does this only happen with coverage.py? What happens if you simply delete that file from your tmp installation?

  4. Skip Montanaro reporter

    This is the first external Python package I've experienced this with. Deleting the site.{py,pyc} files from the temp installation, then repackaging, seems to work fine. I did that to verify that coverage.py still works as it should. We don't actually have site.py in our setup, so whatever was in that file (I didn't look closely), really messed things up. I have no idea what it was supposed to do.

    As for the style of install, I'm just following my nose. I need to install into a clean directory tree so I can just tar it up for publishing. With many Python packages, I'm able to do something like this:

    python setup.py install --prefix=/var/tmp/somewhere-beautiful

    and it will just work. Others complain that /var/tmp/somewhere-beautiful/lib/python2.7/site-packages isn't in PYTHONPATH. So I add it. Then I sometimes have to mkdir -p that directory (it generally doesn't exist).

    Using a virtualenv for this sort of exercise doesn't seem like it would be the right thing. By definition, it's an environment which is complete except for the package I'm installing. I want to install in a completely empty directory so I can bundle it up for canned distribution.

    Hmmm... I do see one difference between the last time I installed coverage.py and this time. Another developer installed setuptools 18.5, pip 7.1.2, wheel 0.26.0 and virtualenv 13.1.2 last November. It looks like setuptools is the culprit. It contains a file named site-patch.py which is identical to the site.py which I found hidden in my package.

    I think this can be closed. I doubt there's much you could (or should) do to worm around this problem. Thanks for the assistance.

  5. Log in to comment