Comment by epistasis | Hacker News Reader

Comment by epistasis | Hacker News Reader

Parent Full thread

These are good points. But I think there needs to be an explanation why conda hasn't taken off more. Especially since it can handle other languages too. I've tried to get conda to work for me for more than a decade, at least once a year. What happens to me:

1) I can't solve for the tools I need and I don't know what to do. I try another tool, it works, I can move forward and don't go back to conda

2) it takes 20-60 minutes to solve, if it ever does. I quit and don't come back. I hear this doesn't happen anymore, but to this day I shudder before I hit enter on a conda install command

3) I spoil my base environment with an accidental install of something, and get annoyed and switch away.

On top of that the commands are opaque, unintuitive, and mysterious. Do I do conda env command or just conda command? Do I need a -n? The basics are difficult and at this point I'm too ashamed to ask which of the many many docs explain it, and I know I will forget within two months.

I have had zero of these problems with uv. If I screw up or it doesn't work it tells me right away. I don't need to wait for a couple minutes before pressing y to continue, I just get what I need in at most seconds, if my connection is slow.

If you're ina controlled environment and need audited packages, I would definitely put up with conda. But for open source, personal throw away projects, and anything that doesn't need a security clearance, I'm not going to deal with that beast.

Conda is the dreaded solution to the dreadful ML/scientific Python works-on-my-computer dependency spaghetti projects. One has to be crazy to suggest it for anything else.

uv hardly occupies the same problem space. It elevates DX with disciplined projects to new heights, but still falls short with undisciplined projects with tons of undeclared/poorly declared external dependencies, often transitive — commonly seen in ML (now AI) and scientific computing. Not its fault of course. I was pulling my hair out with one such project the other day, and uv didn’t help that much beyond being a turbo-charged pip and pyenv.

Eh, ML/scientific Python is large and not homogeneous. For code that should work on cluster, I would lean towards a Docker/container solution. For simpler dependancy use cases, pyenv/venv duo is alright. For some specific lib that have a conda package, it might be better to use conda, _might be_.

One illustration is the CUDA toolkit with torch install on conda. If you need a basic setup, it would work (and takes age). But if you need some other specific tools in the suite, or need it to be more lightweight for whatever reason then good luck.

btw, I do not see much interest in uv. pyenv/pip/venv/hatch are simple enough to me. No need for another layer of abstraction between my machine and my env. I will still keep an eye on uv.

I always enjoyed the "one-stop" solution with conda/mamba that installed the right version of cudatoolkit along with pytorch. How do you handle that without conda? (I'm genuinely ask because I never had to actually care about it.) If I manually install it, it looks like it is going to be a mess if I have to juggle multiple versions.

Oh I'm not saying conda is a good solution for all ML/scientific. I was making the assertion that it's terrible for basically everything else.

My bad! As you said, this part of Python code bases is chaotic (:

Add to that the licensing of conda. In my company, we are not allowed to use conda because the company would rather not pay, so might as well use some other tool which does things faster.

conda (the package) is open source, it's the installer from Anaconda Corp (nee ContinuumIO) and their package index that are a problem. If you use the installer from https://conda-forge.org/download/, you get the conda-forge index instead, which avoids the license issues.

We've been working on all the shortcomings in `pixi`: pixi.sh

It's very fast, comes with lockfiles and a project-based approach. Also comes with a `global` mode where you can install tools into sandboxed environments.

I am trying to configure Pixi to use it with Artifactory proxy in a corporate environment, still could not figure it out how to configure it.

Join our discord and we can help! There are lots of users that run it with Artifactory :)

I'd probably check this out in my home lab but as a corporate user the offering of discord as a support channel makes me nervous.

Discord is predominately blocked on a corporate networks. Artifactory ( & Nexus) are very common in corporate environments. Corporate proxies are even more common. This is why I'd hesitate. These are common use cases (albeit corporate) that may not be readily available in the docs.

My completely unvarnished thoughts, in the hope that they are useful: I had one JIRA-ticket-worth of stuff to do on a conda environment, and was going to try to use pixi, but IIRC I got confused about how to use the environment.yml and went back to conda grudgingly. I still have pixi installed on my machine, and when I look through the list of subcommands, it does seem to probably have a better UX than conda.

When I go to https://prefix.dev, the "Get Started Quickly" section has what looks like a terminal window, but the text inside is inscrutable. What do they various lines mean? There's directories, maybe commands, check boxes... I don't get it. It doesn't look like a shell despite the Terminal wrapping box.

Below that I see that there's a pixi.toml, but I don't really want a new toml or yml file, there's enough repository lice to confuse new people on projects already.

Any time spent educating on packaging is time not spent on discovery, and is an impediment to onboarding.

Have you used the contemporary tooling in this space? `mamba` (and ~therefore, `pixi`) is fast, and you can turn off the base environment. The UX is nicer,too!

Reply on news.ycombinator.com