[conda] Support Python environments embedded inside Conda environments? #451
Comments
jherland
added
type: feature request
research-needed
needs-real-projects-test
|
I've started looking at Pixi (as part of #453 and eventually #454), and it appears to construct environments that are very similar to Conda environments (as laid out above). These are the only differences I can see after a cursory inspection:
My initial impressions is that FawltyDeps (as of v0.17.0) is already able to find and use Python packages in a Pixi environment when e.g. |
|
FWIW, when FawltyDeps itself is installed into a Pixi environment (with I suspect something similar applies when FawltyDeps is installed inside a Conda environment, but I haven't yet tried installed PyPI packages inside a Conda environment (and FawltyDeps is not distributed as a Conda package). As an interesting corner case, if the Pixi project is using |
|
A reminder to myself that we also need to look at Pixi/Conda environments on Windows, and how they differ from corresponding Linux environments. (I assume MacOS Conda environments are ~identical to corresponding Linux environments, just like as Python virtualenvs are.) |
|
Reading up on Mamba (another modern Conda alternative) it seems that environments in Mamba (Conda too?) can be "stacked" on top of a base environment, where packages installed in the base environment are automatically also available in any other environment based on top that. Also, it appears environments can be stacked when you activate them:
How this should be handled by FawltyDeps is not entirely clear yet. Worst case, the user should always be able to simply pass multiple |
(found while exploring potential Conda support for FawltyDeps, see e.g. #447 for more context)
I'm following the documentation at https://www.activestate.com/resources/quick-reads/how-to-manage-python-dependencies-with-conda/ to see what a Conda environment looks like, and what would be needed from FawltyDeps to use it for deducing the package-name -> import-name mapping.
Specifically, after running the following commands:
there are no files/directories created inside the current directory (like you would expect with e.g. Poetry or a similar (virtual) environment manager). Instead, there is a
my_conda_project/subdirectory created under~/.conda/envs/, and inside this directory we find:This seems roughly to be a superset of a virtual environment: It contains more than just Python packages (which Conda is known to support), but it also contains the stuff we'd expect to find in a virtualenv (possibly except a
pyvenv.cfgat the root of the env):bin/pythonlib/pythonX.Y/site-packages/...Fortunately, for the purposes of matching package names to import names in Python, we can hopefully get away with ignoring the rest of the Conda environment, and focusing only on the subset that it has in common with virtualenvs.
And this seems to already work, in the sense that passing
--list-sources --pyenv ~/.conda/envs/my_conda_projectdoes indeed find~/.conda/envs/my_conda_project/lib/python3.8/site-packagesas a valid Python environment, and FawltyDeps is also able to resolve package names to import names from that directory.Thus, this preliminary investigation indicates that this issue might already be solved, but I propose keeping it open until we have built some more confidence that we indeed support this properly.
The text was updated successfully, but these errors were encountered: