sandboxing causes all skylark rules with tools relying on /usr/local/bin/python to fail

[msolo-dropbox]

Replacing /usr/bin/python with a custom version is not an option most systems, thus /usr/local/bin/python is a necessity.

What is the escape hatch to make this work again?

Feels like "sandbox" is really just an ad-hoc container. Perhaps it would be better to just configure that as part of the workspace. Specifying if sandbox is generally enabled, and if so, what paths to allow would be much clearer.

Thinking further ahead, it would be even better to just allow the "sandbox enter" command to work with something like a docker container. That would make it much easier to debug and fix issues quickly.

[damienmg]

This is due of /usr/local not being mounted in the sandbox. @philwo : do you have any insight on the good fix for that?

[damienmg]

Should be fixed by using python as an external repository but that's not necessarly convenient right now

[msolo-dropbox]

That seems pretty arduous. I think some way of configuring what goes in the
sandbox is going to be necessary. The easiest thing might be to allow a
reference to a file_group or a tar package.

On Tue, Nov 17, 2015 at 4:05 AM, Damien Martin-Guillerez <
notifications@github.com> wrote:

Should be fixed by using python as an external repository but that's not
necessarly convenient right now

—
Reply to this email directly or view it on GitHub
#576 (comment).

[bsilver8192]

The sandbox is separate for every action Bazel runs. It includes only the declared inputs and some standard system folders (/proc, /usr/bin, /usr/lib, etc). If you have a tar file or a filegroup, you can add it as an input to the action and it will then be included in the sandbox when appropriate. Also, as of f96edf7, can use execution_requirements = { 'local': 'local' } to disable the sandbox for individual actions.

[damienmg]

@msolo-dropbox once we get that configuration, we are probably going to do it. It's shouldn't be hard for the users. Configuring the sandbox might not be a great idea (ideally, nothing but declared dependencies should be mounted in it).

[damienmg]

Closing as duplicate for #544 (note that the mechanism now exists and we should do it)

[philwo]

@damienmg What mechanism exists and what should we do? Do you mean adding paths to the sandbox (Yue has a pending CL implementing this), or adding a filegroup for /usr/local (but that doesn't work if there are filenames that are no valid labels)?

[damienmg]

See "Should be fixed by using python as an external repository but that's not necessarly convenient right now"

[philwo]

OK, and what do you mean with "we should do it"? What is "it"? Access Python via an external repository in all of Bazel? I don't see how that could work, considering that Python is installed in a different place in each Linux distribution and OS X.

Or should our users define their own external_repository for /usr/local, add a filegroup that matches Python and then depend on that from all their py_* targets?

[damienmg]

We do auto-detection just like we do for C++.