Hacker News new | ask | show | jobs
by japanuspus 539 days ago
The problem conda solved that nothing had solved before was installing binary dependencies on MS Windows.

Before conda, getting a usable scipy install up and running on MS Windows was a harrowing experience. And having two independent installations was basically impossible. The real hard work that went into conda was reverse engineering all the nooks and crannies of the DLL loading heuristics, to allow it to ensure that you loaded what you intended.

If you are working on macOS and deploying to some *nix in the cloud, you are unlikely to find any value in this. But in ten years as lead on a large tool that was deployed to personal (Windows) laptops in a corporate environment, I did not find anything that beat conda.

2 comments

This was mostly because most scientific packages didn't provide Windows binary builds for many years.

Today you can just "pip install scipy" on Windows at it will just work.

Oh right, recently I started learning classic ML and “just” tried to install tensorflow, which, itself or through one of dependencies, stopped providing windows binaries since x.y.z and so my python has to be downgraded to 3.a and then other dependencies stop installing. Eventually I managed to find a proper version intersection for everything together with some shady repo, but it felt like one more requirement and I’ll get overconstrained.
Tensorflow is the worst. Basically every time my python env was borked (with multiple incompatible versions of Numpy) it was down to tensorflow.
You said it. I was working with an official Google library that used TF and it didn’t work at all with 3.12. I spent a day building the wheels for 3.12 only to find there was a bug with dataclasses. :|

I can’t recall the library, but there was another major project that just deprecated TF because it was the cause of so many build problems.

It also made a bunch of neural net libraries much easier to install before containers became popular.