Allow to customize location of .eggs directory

Apparently the PYTHON_EGG_CACHE environment variable does not affect the location of the .eggs directory when building a Python package using a command like python setup.py build: https://github.com/pypa/setuptools/blob/38b9010bc3527e89561c7a985e0908a3071b7ff5/setuptools/dist.py#L745

My code lives in a read-only partition mounted into a Docker container and therefore the build fails:

...
  File "/usr/local/lib/python3.6/dist-packages/pkg_resources/__init__.py", line 1077, in obtain
    return installer(requirement)
  File "/usr/local/lib/python3.6/dist-packages/setuptools/dist.py", line 778, in fetch_build_egg
    install_dir = self.get_egg_cache_dir()
  File "/usr/local/lib/python3.6/dist-packages/setuptools/dist.py", line 747, in get_egg_cache_dir
    os.mkdir(egg_cache_dir)
OSError: [Errno 30] Read-only file system: './.eggs'

Setting the PYTHON_EGG_CACHE variable has no effect on this behavior, but I guess it should?

[gilbsgilbs]

It’s not a valid use case, because you need write support to generate the egg-info metadata. And yes, .eggs and .egg-info directory are generated in the source directory.

The point of this issue is that you could write them both in the current working directory (or somewhere else) instead of the project’s directory if write isn’t available there. Is there a specific reason why this would not be possible or desirable? Apart from saying “it’s not a valid use-case” while not suggesting a portable solution to a use-case that does exist for at least two people (and probably more).

Edit: FWIW, this is a polite and understandable yet firm answer. Saying “It’s not a valid use-case” out of nowhere is just being mean and condescending to the users and that doesn’t help. I feel disappointed this kind of behavior is still present in the python packaging community…

[craigphicks]

@gilbsgilbs @tgpfeiffer I had a slightly different problem when specifying an install directory

$ easy_install --install-dir /opt/myapp  myapp.egg
<fail message>

it erred out with a message that it could only write to a valid site-packages directory. As I workaround I set up a virtual environment and activated it

$ python3 -m venv --prompt myapp /opt/myapp
$ /source opt/myapp/bin/activate
(myapp)$ easy_install --install-dir /opt/myapp  myapp.egg
<success message>

As a result under /opt/myapp/lib/site-packages/lib were mostly many compact ‘.egg’ files, and under '/opt/myapp/share were many compact wheel files. The total memory used by the virtual environment only (containing python3, etc.) was 8mb, a small fraction of the total compact installed ‘myapp’ which came to 84mb.

Of course to call ‘myapp’ pre-requires another call to ‘’’
$ /source opt/myapp/bin/activate ‘’’ I don’t grasp your exact usage requirements, but there seemed enough potential overlap I thought it might be worth posting this message.