pbr's setup.py bdist_egg fails on Windows with a SandboxViolation exception
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
PBR |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
zope.testrunner, when used with Python 2.6, depends on unittest2, which setup_requires traceback2, which setup_requires pbr, which fails to install on our Windows buildbot: https:/
You can find the full output of bin/buildout -vvv at https:/
Running pbr-0.10.8\setup.py -q bdist_egg --dist-dir c:\temp\
Importing new compiler from distutils.
warning: no previously-included files found matching '.coveragerc'
warning: no previously-included files found matching '.mailmap'
warning: no previously-included files found matching '.travis.yml'
warning: no previously-included files found matching 'pip\_vendor\
warning: no previously-included files found matching 'tox.ini'
warning: no previously-included files found matching 'dev-requiremen
warning: no files found matching 'Makefile' under directory 'docs'
no previously-included directories found matching '.travis'
no previously-included directories found matching 'docs\_build'
no previously-included directories found matching 'contrib'
no previously-included directories found matching 'tasks'
no previously-included directories found matching 'tests'
error: Setup script exited with error: Setup script exited with error: SandboxViolation: open('build\
In case you're not familiar with zc.buildout: the important thing is that it wraps easy_install from setuptools to do the installation. Unfortunately I haven't been able to reproduce this failure using a virtualenv's scripts/
Curiously, this is not the first invocation of pbr's setup.py in the build log, but the previous ones succeed.
I have a theory that this failure may be caused by the deep nesting of the directory trees, caused by the chain of nested setup_requires. Perhaps a filename gets too long for Windows and setuptools has a try/except that mistakenly converts that into a SandboxViolation exception? I've a log of a different buildout run, with a longer %TEMP% directory name, which fails due to filename length problems -- https:/ /gist.github. com/anonymous/ 4f3631e0ed119a0 876d9. Still, the evidence is inconclusive.