My company has a build machine that has been regularly building eggs for years without a problem and yesterday we noticed that we started getting an exception mentioned above. We thought we had locked the version of setuptools we are using to 0.6.c11, but evidently it has been mysteriously going out and upgrading to the latest version of setuptools even though we used --no-site-packages and specify the repository to look at. I read that this problem was fixed with setuptools 0.7.6, but I'm still seeing the problem. So, I have two questions: 1) Do you know how I can prevent setuptools from getting updated to the latest version, and 2) Is the fix that mentioned here for distribute actually in the 0.7.6 setuptools?
I've patched the code again and re-released as Distribute 0.6.48 and Setuptools 0.7.7 and 0.8b5. Sorry for all the noise. As a result, I raised the priority of setuptools #30 and added a test to verify the fix. Please report back if this doesn't address the issue.
@David Kindred Regarding (1), it depends on how setuptools 0.7 is being installed. In general, you have to invoke 'easy_install -U' or 'pip install --upgrade' to cause setuptools to be upgraded. Or, if you don't have setuptools at all, invoking ez_setup.py will always get the latest, because it only specifies a lower bound. You'll have to investigate in your particular environment to determine when the upgrade is happening and alter that command to avoid the upgrade. Except when stupid bugs like this one are present, however, 0.7 is generally recommended over 0.6.
Sorry for any inconvenience. I hope soon to provide a full report explaining the underlying security problem and why this effort was back-ported to Distribute.
Unfortunately there is another exception, which occurs when extraction directory does not exist:
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 914, in resource_filename
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 1602, in get_resource_filename
return self._extract_resource(manager, zip_path)
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 1657, in _extract_resource
manager.extraction_error() # report a user-friendly error
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 960, in extraction_error
pkg_resources.ExtractionError: Can't extract file(s) to egg cache
The following error occurred while trying to extract file(s) to the Python egg
[Errno 2] No such file or directory: '/home/Arfrever/.python-eggs'
The Python egg cache directory is currently set to:
Perhaps your account does not have write access to this directory? You can
change the cache directory by setting the PYTHON_EGG_CACHE environment
variable to point to an accessible directory.
The original exception (OSError: [Errno 2] No such file or directory) is caused by the following line in _warn_unsafe_extraction_path():
mode = os.stat(path).st_mode
Maybe something similar to the following loop should be used (before above line):
if (os.name == 'nt' and os.path.exists(os.path.split(path)) or
os.name != 'nt' and path.startswith(os.path.sep)):
while not os.path.exists(path):
path = os.path.dirname(path)
return # Fully invalid path, so there will be an exception anyway
This new failure is fixed in Setuptools:1973ab2fe0b9, which simply does the warning check following ensuring that the directory exists. I verified that the reported error exists before the change and does not exist after.