SandboxViolation installing jsonpickle #20

jaraco opened this Issue Sep 28, 2011 · 2 comments


None yet
2 participants

jaraco commented Sep 28, 2011

We recently ran into an error installing jsonpickle on our system where simplejson was installed as a zipped egg:

Processing dependencies for gryphon==3.9b3
Searching for jsonpickle
Best match: jsonpickle 0.4.0
Processing jsonpickle-0.4.0.tar.gz
Running jsonpickle-0.4.0/ -q bdist_egg --dist-dir /tmp/easy_install-AzSx_I/jsonpickle-0.4.0/egg-dist-tmp-Ft4uq4
error: SandboxViolation: chmod('/var/lib/jenkins/.python-eggs/simplejson-2.1.3-py2.7-linux-x86_64.egg-tmp/simplejson/tmpozJqL9.$extract', 493) {}

The package setup script has attempted to modify files on your system
that are not within the EasyInstall build area, and has been aborted.

This package cannot be safely installed by EasyInstall, and may not
support alternate installation locations even if you run its setup
script by hand.  Please inform the package's author and the EasyInstall
maintainers to find out if a fix or workaround is available.

It appears the problem lies when the jsonpickle setup script tries to determine its version. To accomplish this task, it first imports jsonpickle, which causes the backends to be loaded, which causes simplejson to be imported, which causes setuptools to expand the zipped egg, which violates the setuptools Sandbox.

It would be much better if jsonpickle were able to determine its version without initializing jsonpickle.

I could imagine several ways this could be done.

  1. Store the version in a file, import that in jsonpickle.init and execfile it from
  2. Store the version in and depend on setuptools to determine the version in jsonpickle.init (See the eggmonster package for an example of how this might be done).
  3. Store the version redundantly in and
  4. Set a flag (environment variable or similar) that tells jsonpickle.init not to initialize the engine when running

I can think of other alternatives as well, but none as attractive as the above. My preference would be for 1, but I'll leave it to the maintainers to find a fix that suits their style best.

If you would like me to implement the fix, just say so (and if you have any preference for the approach), and I'll fix it in a fork.



davvid commented Apr 25, 2013

Yes, this would be good to fix. I did a first stab and I believe no longer contains any jsonpickle imports. I did it by doing (3), which is not ideal. If you would like to pursue doing something like (1) then that would be really helpful and appreciated. execfile -- is that deprecated in py3? I guess we could do exec( which would do it.

I thought keeping the version in was pretty common?.. oh well. I wonder why execfile is not a violation but import is? Is it because the build scripts should never depend on the thing being built? That seems sensible, though a little inconvenient. Thanks for all the help.


jaraco commented May 30, 2013

I suspect simply doing execfile on jsonpickle/ will not help. By doing execfile on jsonpickle/, it bypasses the package structure and prevents execution of jsonpickle/

@davvid davvid closed this in d854395 May 31, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment