Closed kcpevey closed 9 months ago
This is specific to Nebari because in the Nebari usage of conda-store, the conda folders are readonly so pip uses .local instead.
@costrouc suggested that we could use https://pip.pypa.io/en/stable/cli/pip/#cmdoption-require-virtualenv
I assume this would mean we would need to do a double activation. activate conda env and then the virtualenv. This should work from a terminal but not sure how you could do that within Jupyter.
If this is nebari specific - can we move the issue to the nebari repo?
Apologies, I had the wrong repo... https://github.com/nebari-dev/nebari/issues/2133
Feature description
Currently, if I add a pip section to my
environment.yml
, the packages get added to my private.local
space. However, if I have a second environment which does the same thing, THOSE get added to the.local
space as well. This creates a situation where the pip packages from BOTH environments are now available in BOTH environments.The real kicker is that if the second environment required different versions of the pip packages, it goes ahead and updates the
.local
, leaving the first environment in a broken state.This happens very much behind the scenes and users have no idea what happened to their first environment since they "didn't touch it".
We should isolate the pip installed packages so that there is no cross-contamination between environments.
Value and/or benefit
Clean, isolated environments that pip can't break and happy users :)
Anything else?
No response