Prototypes a new isolation interface

[miguelgondu]

No description provided.

[miguelgondu]

Hi @SimonBartels, @RMichae1.

Could I ask you to take a look into the last two tests of test_force_isolation.py? Don't worry about the other files for now.

I'm prototyping a new isolation interface that will hopefully be more reliable than the current one we have. In a nutshell:

• we stop using conda.
• we stop registering problems.
• The user simply provides a python executable in which to run the isolated script.

Something like:

frompathlibimportPathfrompoli.objective_factoryimportcreateproblem=create(
name="rasp",
wildtype_pdb_path=Path(__file__).parent.parent/"static_files_for_tests"/"3ned.pdb",
python_executable_for_isolation="/Users/sjt972/anaconda3/envs/poli__rasp/bin/python",
)

[SimonBartels]

Interesting approach. So the environment is defined through the executable? Sounds awesome. This also implies support for virtualenv and what not, right?
Yeah, maybe this is the easier solution. In my case, the executable is essentially determined by the problem name, which is why I like a registry. But I also see that this approach is more transparent for new users, less error-prone for them, and it's a good trim for poli.

[miguelgondu]

Yeah, precisely. We should only assume that the user has python. Assuming that they have virtualenv, conda, mamba or uv imposes a lot on us, and adds restrictions to the user. It would also allow us to put poli on pypi.

That being said, I still think we should provide conda envs in which things run reliably.

[miguelgondu]

It seems that running w. the python executable of an env is not enough, because a conda activate modifies the path: https://stackoverflow.com/a/65564255

[SimonBartels]

Hm. And there are other possible environment changes affecting for example numpy through a different glibc or what not. What's your current stance?