No description provided.
I don't like that there are three places that say "bin/python". Some of this could go away if we drop the CODEJAIL_TEST_VENV environment variable. It isn't documented in the readme, and I managed the same effect by activating the edx-platform venv before running the codejail tests.
I'm not done with this, but it'd be good to get some eyeballs on it early :)
I don't think this is the right place to add this logic. edx-platform should be deciding where it wants its sandboxes created, not codejail.
At the most, codejail should provide an option to autocreate a sibling env, but the importing code should have to opt in to it, perhaps by an environment variable, or some other setting.
I would love for you to help figure out how to do that. Keep in mind that the tests need pass, both with and with sandboxes in the environment. We have Django middleware that configures codejail, but that middleware isn't run during the safe_exec tests, since they are not in a Django app.
Thanks! Let me know when this is ready for a for-real review.
Updates to use the latest refactoring with edx-platform
* Python 2.x is called "python" again
* Provide "configure_python" so that edx-platform can get convenient
@jcdyer ready for real review.