Closed jaimergp closed 6 months ago
I'm not too sure yet about writing the files directly to the target environment. It creates the opportunity for lingering files unless the user removes packages nicely. Maybe an alternative is to inject a fake conda-meta/externally-managed-1.0-py3xy.json
metadata file that lists the EXTERNALLY-MANAGED
file so it can be conda remove
d nicely. I'll leave that for a further issue.
Pinging @jezdez @pradyunsg for awareness / comments if time allows :)
Closes #1
In this PR, we are implementing the following behavior:
conda-pip
packaged files includeEXTERNALLY-MANAGED
by default. This protects thebase
environment (or whateverconda-pip
has been installed to; usuallybase
).EXTERNALLY-MANAGED
afterconda pip -p target install ...
executions.EXTERNALLY-MANAGED
if the target environment haspip
.lib/pythonX.Y
directory to the new one.pip
is not present in the target environment anymore.conda-pip
is present inbase
as a dependency and not explicitly installed (we check the history file for explicit presence ofconda-pip
).To do / discuss:
conda remove --all
is invoked? This should be caught by the post-command plugin anyway, but a few empty directories might be in place? Maybeconda
clears the tree? Investigate.conda env remove
.References: