4 ms·
For conda it’s an unfair characterisation. Conda is language agnostic and can be (and is) used to ship anything. Packages like GCC/Clang/R will never be accessi
by tempay 6y ago
For conda it’s an unfair characterisation. Conda is language agnostic and can be (and is) used to ship anything. Packages like GCC/Clang/R will never be accessible for venv. Personally I find it magical to be able to ship complex packages on conda-forge that “just work” on Linux/macOS/Windows/ARM/POWER without requiring users to have special privileges.
- PaulHoule 6y agoI'm tempted to say "so what?" Here's a specific example. In a previous job I had to work with Tensorflow models of various vintages that depended on different versions of CUDA. Conda (out of the box) did nothing to help with that problem. I think an early version of Conda might have installed one early version of CUDA, but the elephant in the room as that I would need to install as many versions of CUDA as necessary. NVIDIA uses a lot of intimidation to fool people as to the nature of the drivers. Specifically, CUDA/CuDNN and such don't depend on kernel drivers or Windows installers, but just require that some huge directories full of userspace libraries be on your path. Thus you can have CUDA version A linked into one conda environment, and CUDA version B linked into another conda environment and it all worked. That is, it worked when I made my own conda packages (conda wasn't allowed to distribute such package by NVIDIA) and it was astonishingly slow because conda stores packages in BZIP2 files that take forever to unpack and because conda wastes more time with it's symlink machine. In the end it was possible to solve the problem w/ conda but if I hadn't been distracted by conda I probably would have solved it just as quickly by unpacking the userspace drivers once and just setting the path appropriately.