Add support for conda env variables

[gonzalocasas]

Feature Request

As a user of compas.rpc in conda environments, I want the RPC server to pickup and assign the environment variables defined in the environment itself so that 'life is wonderful and things works friction-less'.

Details

Is your feature request related to a problem? Please describe. Conda allows (since recent times, I believe) to set env variables that are 'attached' to a specific environment (see here for details). These variables are not in the host process, so when compas.rpc.Proxy launches the server in the environment, those are not taken into account.

Describe the solution you'd like The solution should read this vars and set them during the init phase of the RPC server when launched by the Proxy.

Describe alternatives you've considered As a simple workaround, the RPC server can be started from the environment, but that's sometimes not desirable because then the behavior of the Proxy auto-start and the manual start differ.

[gonzalocasas]

/cc @mhelmrei

[tomvanmele]

do i understand correctly that the goal is that RPC loads the environment variables of the environment of the client into the environment of the server?

[gonzalocasas]

not quite ;) The RPC should load the environment variables defined in the environment itself into the environment of the server.

Steps to repro would be

1. create an environment
2. configure some env var inside of it, using conda's (new) command: conda env config vars set GREATVARIABLE=3.14
3. without manually starting the RPC server, use the Proxy which should kick off the server in a background process

Expected result

• the server (started in a process by the client) should have loaded GREATVARIABLE into its environment vars.

[gonzalocasas]

the simple workaround for this is just to manually start the RPC server from the activated environment, because that case, there's no environment reconstruction and all env vars are immediately available.

[tomvanmele]

but so in the scenario you are describing the "environment itself" is not the environment that was active when the server was launched the first time?

[tomvanmele]

so for example, in the case when one unknowingly reconnects to a proxy server that was originally launched from a different environment?

[gonzalocasas]

I'm a bit lost with your question, I'll try to clarify naming all environments.

Setup is:

1. A conda environment named envA with compas installed
2. An environment variable GREATVARIABLE=3.14 defined only in the envA environment
3. GREATVARIABLE is not available in the base environment, nor as a system-wide var, only inside envA and it is conda the one that handles setting it every time the environment activates
4. Rhino running as usual, with no access to anything in conda environments, hence also no access to GREATVARIABLE
5. No RPC server already running.
6. A python script makes use of compas.rpc.Proxy()
7. The first use of Proxy causes the RPC server to be launched in a separate process, this process is intended to be running an activated envA environment (which we pseudo-activate ourselves by reconstructing the some variables such as CONDA_EXE and PATH to be more or less what conda does)
8. The expectation is that the server launched in the previous point has access to GREATVARIABLE.

[tomvanmele]

okay so we basically inspect the target environment, for example using CONDA_EXE, find all defined/stored environment variables (stored by conda or otherwise) and load them into the process running on the server, as conda would do when you activate an environment in the terminal?

[gonzalocasas]

yes, exactly :)

[jf---]

@gonzalocasas what possible could be improved in compas.rpc.Proxy its magical

[gonzalocasas]

I am not sure this is so important anymore, because it's a really niche feature of conda to allow this env-specific environment variables. We could close it

[jf---]

🔒