Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add the concept of branching in the Virtual Environment Manager #13894

Open
2 tasks done
showkeyjar opened this issue May 6, 2024 · 2 comments
Open
2 tasks done
Labels
source::community catch-all for issues filed by community members type::feature request for a new feature or capability

Comments

@showkeyjar
Copy link

Checklist

  • I added a descriptive title
  • I searched open requests and couldn't find a duplicate

What is the idea?

Make the virtual environment no longer a flat structure, but a tree structure containing root and branch nodes.

Why is this needed?

I create 10 of environments, it all contain some big packages, for example pytorch, tensorflow etc.
Repeatedly installing huge packages wastes time and space.
Unfortunately, if there is a slight conflict between certain small packages, a new environment must be created.

What should happen?

If conda has branch functions, I can create a root env, install pytorch

then create level1 level2 env1, env2 from root, and then, install those small different packages in env1, env2.

Additional Context

Eagerly anticipating the launch of this feature

@showkeyjar showkeyjar added the type::feature request for a new feature or capability label May 6, 2024
@travishathaway travishathaway added the source::community catch-all for issues filed by community members label May 7, 2024
@jaimergp
Copy link
Contributor

jaimergp commented May 7, 2024

Unfortunately this is a bit trickier than it looks like. Most conda packages with compiled objects will have been built to link to dynamic libraries in a relative path (usually something like ../lib/mylib.so). If we branch environments like that, there's a chance the required libraries won't be in place to be found. We would need to start adding symlinks in all required places and... well that would end up looking like a flat environment again :)

Another clarification, most of the files are not copied but hardlinked. So the disk usage overhead is actually tiny. If you are concerned about the time spent while hardlinking, then a more interesting approach would be to implement copy-on-write linking.

@showkeyjar
Copy link
Author

thanks for your attention.

first, dynamic libraries problem:
There are two types of files that need to be distinguished here: old packages in root env and new packages in branchs envs.
old packages no need to recompiled, new package compiled in branchs envs separately.
so I think it's not problem.

second, tree structure of envs:
I understand your description, but conda only has one root env(base),
for example, if I want create two different root env: pytorch and tensorflow
and then, I create p1,p2 from pytorch env, create t1, t2 from tensorflow env,
it still hardlinked files?
I test those operation on my windows computer, but disk still increase huge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
source::community catch-all for issues filed by community members type::feature request for a new feature or capability
Projects
Status: 🆕 New
Development

No branches or pull requests

3 participants