Deprecate EXEC_ENV

[jondequinor]

Its only user, RMS, uses it to shadow PYTHONPATH for RMS jobs. RMS run method should instead get PYTHONPATH as the eight argument.

[markusdregi]

I think we should at least consider executing this issue.

[jondequinor]

EXEC_ENV. Sounds generic. Sounds potent! But, alas, it is neither.

This is probably how EXEC_ENV is used today:

EXEC_ENV {"foo": null, "bar": "qux"}

is entered by the user into an ERT configuration. This is then, by job_dispatch.py—on the cluster or locally, depending on queue configuration—dumped into the runpath as {executable}_exec_env.json.

rms_run.py then reads this file and applies it for some RMS executable. The environment of that executable will be manipulated as follows:

• if foo exists in the environment, it is removed
• bar is set to qux

So, is it used for any other "environments" or "executables" like ert itself, workflows or other official forward models? No, not as far as I can see.

Can it do special thing to the "execution" "environment"? No, it sets or unsets variables. It's run-of-the-mill os.environ jiggling.

Do users write their own forward models that picks up {executable}_exec_env.json? If you write your own forward model, why wouldn't you just manipulate the environment directly?

It seems like a really bad name for a very specific RMS feature.

For developers, it is odd that, if the above is true, that it's so prominent in the job_dispatch.py and related code. The developer would think the job_runner used by job_dispatch.py system should strive to be generic, but currently it has a bunch of code dealing specifically with EXEC_ENV. So, from a ERT developer point of view, EXEC_ENV is carried up until execution of the forward model, but the buck kind of stops there. Nothing except the RMS FM will care about this json file.

If the code is not generic, it should be removed or replaced in favor of something generic. Can we make EXEC_ENV generic? Should we, in all our forward models, read and manipulate the environment as per EXEC_ENV? Probably not.

We could deprecate EXEC_ENV, suggest that the user copies a pre-populated {executable}_exec_env.json with COPY_FILE whenever it's required by an RMS job.

If this is tricky, we could provide the user with a new configuration option called UPDATE_FORWARD_MODEL_ENVIRONMENT which takes a forward model and some chunk of data to capture the intent.

UPDATE_FORWARD_MODEL_ENVIRONMENT rms_job_1 {"add_keys": [{"bar": "qux"}, …], "remove_keys": ["foo"]}

This would not surprise anyone.

[oyvindeide]

Blocked by: https://github.com/equinor/rms-sys/pull/208

[berland]

Blocked by: equinor/rms-sys#208

Unblocked now.