Why does conda not use symlinks for duplicate dependencies? [on hold]

The name of the pictureThe name of the pictureThe name of the pictureClash 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?







share|improve this 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
















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?







share|improve this 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












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?







share|improve this question













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?









share|improve this question












share|improve this question




share|improve this question








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
















  • 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















active

oldest

votes






















active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes

Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay