Why does conda not use symlinks for duplicate dependencies? [on hold]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
1
down vote
favorite
I wondered whether conda actually made duplicate files for certain dependencies shared by independent environments.
I installed two environments env1
and env2
. Then I installed the same module cryptography
in both of them. Next I searched for the module's name in my system with find
and found it in miniconda3/envs/env1/lib/python3.7/site-packages/
as well as miniconda3/envs/env2/lib/python3.7/site-packages/
.
Next I went through all directories from site-packages
on and ls -al
-ed for symlinks. I did not find any symlinks on the path to cryptography
. Hence these must be actual copies of the same module and the same version of it.
Is this not very wasteful of disk space? Why does conda not use symlinks for cases like this? I would like to know the rationale behind this design as I suspect other environment managers handle things the same way?
package-management python symlink anaconda
put on hold as too broad by Thomas Dickey, SivaPrasath, schily, Jeff Schaller, G-Man 2 days ago
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
1
down vote
favorite
I wondered whether conda actually made duplicate files for certain dependencies shared by independent environments.
I installed two environments env1
and env2
. Then I installed the same module cryptography
in both of them. Next I searched for the module's name in my system with find
and found it in miniconda3/envs/env1/lib/python3.7/site-packages/
as well as miniconda3/envs/env2/lib/python3.7/site-packages/
.
Next I went through all directories from site-packages
on and ls -al
-ed for symlinks. I did not find any symlinks on the path to cryptography
. Hence these must be actual copies of the same module and the same version of it.
Is this not very wasteful of disk space? Why does conda not use symlinks for cases like this? I would like to know the rationale behind this design as I suspect other environment managers handle things the same way?
package-management python symlink anaconda
put on hold as too broad by Thomas Dickey, SivaPrasath, schily, Jeff Schaller, G-Man 2 days ago
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
what is "too broad" about it?
â lo tolmencre
yesterday
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I wondered whether conda actually made duplicate files for certain dependencies shared by independent environments.
I installed two environments env1
and env2
. Then I installed the same module cryptography
in both of them. Next I searched for the module's name in my system with find
and found it in miniconda3/envs/env1/lib/python3.7/site-packages/
as well as miniconda3/envs/env2/lib/python3.7/site-packages/
.
Next I went through all directories from site-packages
on and ls -al
-ed for symlinks. I did not find any symlinks on the path to cryptography
. Hence these must be actual copies of the same module and the same version of it.
Is this not very wasteful of disk space? Why does conda not use symlinks for cases like this? I would like to know the rationale behind this design as I suspect other environment managers handle things the same way?
package-management python symlink anaconda
I wondered whether conda actually made duplicate files for certain dependencies shared by independent environments.
I installed two environments env1
and env2
. Then I installed the same module cryptography
in both of them. Next I searched for the module's name in my system with find
and found it in miniconda3/envs/env1/lib/python3.7/site-packages/
as well as miniconda3/envs/env2/lib/python3.7/site-packages/
.
Next I went through all directories from site-packages
on and ls -al
-ed for symlinks. I did not find any symlinks on the path to cryptography
. Hence these must be actual copies of the same module and the same version of it.
Is this not very wasteful of disk space? Why does conda not use symlinks for cases like this? I would like to know the rationale behind this design as I suspect other environment managers handle things the same way?
package-management python symlink anaconda
edited 2 days ago
slmâ¦
232k65479648
232k65479648
asked 2 days ago
lo tolmencre
1285
1285
put on hold as too broad by Thomas Dickey, SivaPrasath, schily, Jeff Schaller, G-Man 2 days ago
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as too broad by Thomas Dickey, SivaPrasath, schily, Jeff Schaller, G-Man 2 days ago
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
what is "too broad" about it?
â lo tolmencre
yesterday
add a comment |Â
what is "too broad" about it?
â lo tolmencre
yesterday
what is "too broad" about it?
â lo tolmencre
yesterday
what is "too broad" about it?
â lo tolmencre
yesterday
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
what is "too broad" about it?
â lo tolmencre
yesterday