If we remove conda setup from CMake completely, that will solve this problem.

I'm leaning towards this approach. Moving the Python environment setup being separate and then the Cmake script checking for dependencies during configuration time?

I'm leaning towards this approach. Moving the Python environment setup being separate and then the Cmake script checking for dependencies during configuration time?

CMake just needs to know where the dependencies are located. By default it could use the conda deps, and override with the env var like before.

I think step 1 is to propose a way to setup the environment that is different, but achieves the same goals. The current CMake-based environment method has 3 elements:

• Conda
• Pip (inside of conda)
• "add_third_party", which is really pip using local paths

Relevant CMake functions:

• ADD_CONDA_PACKAGE
• ADD_CONDA_PIP
• ADD_THIRDPARTY_PACKAGE

After playing with stuff in the https://github.com/SymbiFlow/sphinxcontrib-verilog-diagrams repository I think the following could work.

A conda environment configuration can be described with an environment.yml file. See https://github.com/SymbiFlow/sphinxcontrib-verilog-diagrams/blob/master/environment.yml for example. An environment.yml file can reference a PIP requirements.txt file (again https://github.com/SymbiFlow/sphinxcontrib-verilog-diagrams/blob/master/environment.yml). A requirements.txt file can also reference local paths (IE inside the submodules). It could also reference remote git repositories at specific commit revisions which might be even better?

GitHub

SymbiFlow/sphinxcontrib-verilog-diagrams

Sphinx Extension which generates various types of diagrams from Verilog code. - SymbiFlow/sphinxcontrib-verilog-diagrams

GitHub

SymbiFlow/sphinxcontrib-verilog-diagrams

Sphinx Extension which generates various types of diagrams from Verilog code. - SymbiFlow/sphinxcontrib-verilog-diagrams

Some of the ADD_THIRDPARTY_PACKAGE use setup.py develop, which I believe sets up symlinks to consistent environments between <root>/third_party and the conda environment?

Apparently -e does the same;

-e, --editable <path/url>¶
Install a project in editable mode (i.e. setuptools “develop mode”) from a local project path or a VCS url.

-e can be used in a requirements.txt file it seems....

Apparently -e does the same;

So the key is whether there ever a case where a python library is both installed via pip and needs to be in third_party? I think the only one that comes close is icestorm?