3 ms·

I really want to try this but making the venv to install all the torch dependencies is starting to get old lol. How are other people dealing with this? Is ther

I really want to try this but making the venv to install all the torch dependencies is starting to get old lol. How are other people dealing with this? Is there an easy way to get multiple venvs to share like a common torch venv? I can do this manually but I'm wondering if there's a tool out there that does this.

stavros 3y ago
I generally try to use Docker for this stuff, but yeah, it's the main reason why I pass on these, even though I've been looking for something like this. It's just too hard to figure out the dependencies.
amelius 3y ago
> is starting to get old lol. If it's starting to get old, then this means that an LLM like Copilot should be able to do it for you, no?
- stevenhuang 3y ago
  I mean that I already have like 10 different torch venvs for different projects all with various pinned versions and CUDA variants. Still worth the trade-off of not having to deal with dependency hell, but you start to wonder if there is a better way. All together this is many GBs of duplicated libs, wasted bandwidth and compute.
wczekalski 3y ago
I use nix to setup the python env (python version + poetry + sometimes python packages that are difficult to install with poetry) and use poetry for the rest. The workflow is: > nix flake init -t github:dialohq/flake-templates#python > nix develop -c $SHELL > # I'm in the shell with poetry env, I have a shell hook in the nix devenv that does poetry install and poetry activate.
lukasga 3y ago
Can relate to this problem a lot. I have considered starting using a Docker dev container and making a base image for shared dependencies which I then can customize in a dockerfile for each new project, not sure if there's a better alternative though.
- stevenhuang 3y ago
  Yeah there is the official Nvidia container with torch+cuda pre-installed that some projects use. I feel more projects should start with that as the base instead of pinning on whatever variants. Most aren't using specialized CUDA kernels after all. Suppose there's the answer, just pick the specific torch+CUDA base that matches the major version of the project you want to run. Then cross your fingers and hope the dependencies mesh :p.
eurekin 3y ago
Same here. I'm using conda and eyeing simply installing a pytorch into the base conda env
- lhl 3y ago
  I don't think "base" works like that (while it can be a fallback for some dependencies, afaik, Python packages are isolated/not in path). But even if you could, don't do it. Different packages usually have different pytorch dependencies (often CUDA as well) and it will definitely bite you. The biggest optimization I've found is to use mamba for everything. It's ridiculously faster than conda for package resolution. With everything cached, you're mostly just waiting for your SSD at that point. (I suppose you could add the base env's lib path to the end of your PYTHONPATH, but that sounds like a sure way to get bitten by weird dependency/reproducibility issues down the line.)
  - eurekin 3y ago
    Thank you! First time I come across. Looks very promising

stavros 3y ago

I generally try to use Docker for this stuff, but yeah, it's the main reason why I pass on these, even though I've been looking for something like this. It's just too hard to figure out the dependencies.

amelius 3y ago

> is starting to get old lol. If it's starting to get old, then this means that an LLM like Copilot should be able to do it for you, no?

stevenhuang 3y ago
I mean that I already have like 10 different torch venvs for different projects all with various pinned versions and CUDA variants. Still worth the trade-off of not having to deal with dependency hell, but you start to wonder if there is a better way. All together this is many GBs of duplicated libs, wasted bandwidth and compute.

wczekalski 3y ago

I use nix to setup the python env (python version + poetry + sometimes python packages that are difficult to install with poetry) and use poetry for the rest. The workflow is: > nix flake init -t github:dialohq/flake-templates#python > nix develop -c $SHELL > # I'm in the shell with poetry env, I have a shell hook in the nix devenv that does poetry install and poetry activate.

lukasga 3y ago

Can relate to this problem a lot. I have considered starting using a Docker dev container and making a base image for shared dependencies which I then can customize in a dockerfile for each new project, not sure if there's a better alternative though.

stevenhuang 3y ago
Yeah there is the official Nvidia container with torch+cuda pre-installed that some projects use. I feel more projects should start with that as the base instead of pinning on whatever variants. Most aren't using specialized CUDA kernels after all. Suppose there's the answer, just pick the specific torch+CUDA base that matches the major version of the project you want to run. Then cross your fingers and hope the dependencies mesh :p.

eurekin 3y ago

Same here. I'm using conda and eyeing simply installing a pytorch into the base conda env

lhl 3y ago
I don't think "base" works like that (while it can be a fallback for some dependencies, afaik, Python packages are isolated/not in path). But even if you could, don't do it. Different packages usually have different pytorch dependencies (often CUDA as well) and it will definitely bite you. The biggest optimization I've found is to use mamba for everything. It's ridiculously faster than conda for package resolution. With everything cached, you're mostly just waiting for your SSD at that point. (I suppose you could add the base env's lib path to the end of your PYTHONPATH, but that sounds like a sure way to get bitten by weird dependency/reproducibility issues down the line.)
- eurekin 3y ago
  Thank you! First time I come across. Looks very promising