Hacker News Reader

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.

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.

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.

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!

Conda might have all these features, but it's kinda moot all the time no one can get them to work. My experience with conda is pulling a project, trying to install it, and it then spending hours trying to resolve dependencies. And any change would often break the whole environment.

uv "just works". Which is a feature in itself.

Yes, conda has a lot more features on paper. And it supports non-Python dependencies which is super important in some contexts.

However, after using conda for over three years I can confidently say I don't like using it. I find it to be slow and annoying, often creating more problems than it solves. Mamba is markedly better but still manages to confuse itself.

uv just works, if your desktop environment is relatively modern. that's its biggest selling point, and why I'm hooked on it.

Good to see you again.

>Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years.

Agreed. (I'm also tired of seeing advances like PEP 723 attributed to uv, or uv's benefits being attributed to it being written in Rust, or at least to it not being written in Python, in cases where that doesn't really hold up to scrutiny.)

> The pro and con of tools like uv is that they layer over the base-level tools like pip. The pro of that is that they interoperate well with pip.

It's a pretty big pro ;) But I would say it's at least as much about "layering over the base-level tools" like venv.

> The con is that they inherit the limitations of that packaging model (notably the inability to distribute non-Python dependencies separately).

I still haven't found anything that requires packages to contain any Python code (aside from any build system configuration). In principle you can make a wheel today that just dumps a platform-appropriate shared library file for, e.g. OpenBLAS into the user's `site-packages`; and others could make wheels declaring yours as a dependency. The only reason they wouldn't connect up - that I can think of, anyway - is because their own Python wrappers currently don't hard-code the right relative path, and current build systems wouldn't make it easy to fix that. (Although, I guess SWIG-style wrappers would have to somehow link against the installed dependency at their own install time, and this would be a problem when using build isolation.)

> The only reason they wouldn't connect up - that I can think of, anyway - is because their own Python wrappers currently don't hard-code the right relative path

It's not just that, it's that you can't specify them as dependencies in a coordinated way as you can with Python libs. You can dump a DLL somewhere but if it's the wrong version for some other library, it will break, and there's no way for packages to tell each other what versions of those shared libraries they need. With conda you can directly specify the version constraints on non-Python packages. Now, yeah, they still need to be built in a consistent manner to work, but that's what conda-forge handles.

Ah, right, I forgot about those issues (I'm thankful I don't write that sort of code myself - I can't say I ever enjoyed C even if I used to use it regularly many years ago). I guess PEP 725 is meant to address this sort of thing, too (as well as build-time requirements like compilers)... ?

I guess one possible workaround is to automate making a wheel for each version of the compiled library, and have the wheel version move in lockstep. Then you just specify the exact wheel versions in your dependencies, and infer the paths according to the wheel package names... it certainly doesn't sound pleasant, though. And, C being what it is, I'm sure that still overlooks something.

> I still haven't found anything that requires packages to contain any Python code (aside from any build system configuration). In principle you can make a wheel today that just...

Ah, I forgot the best illustration of this: uv itself is available this way - and you can trivially install it with Pipx as a result. (I actually did this a while back, and forgot about it until I wanted to test venv creation for another comment...)

Besides being much slower, and taking up much more space per environment, than uv, conda also has a nasty habit of causing unrelated things to break in weird ways. I've mostly stopped using it at this point, for that reason, tho I've still had to reach for it on occasion. Maybe pixi can replace those use cases. I really should give it a try.

There's also the issue the license for using the repos, which makes it risky to rely on conda/anaconda. See e.g. https://stackoverflow.com/a/74762864

Not sure what you mean about space. Conda uses hardlinks for the most part, so environment size is shared (although disk usage tools don't always correctly report this).

As far as I understand, the conda-forge distribution and the channel solves a lot issues. But it might not have the tools you need.

Thanks for bringing up conda. We're definitely trying to paint this vision as well with `pixi` (https://pixi.sh) - which is a modern package manager, written in Rust, but using the Conda ecosystem under the hood.

It follows more of a project based approach, comes with lockfiles and a lightweight task system. But we're building it up for much bigger tasks as well (`pixi build` will be a bit like Bazel for cross-platform, cross-language software building tasks).

While I agree that conda has many short-comings, the fundamental packages are alright and there is a huge community keeping the fully open source (conda-forge) distribution running nicely.

I just want to give a hearty thank you for pixi. It's been an absolute godsend for us. I can't express how much of a headache it was to deal with conda environments with student coursework and research projects in ML, especially when they leave and another student builds upon their work. There was no telling if the environment.yml in a student's repo was actually up to date or not, and most often didn't include actual version constraints for dependencies. We also provide an HPC cluster for students, which brings along its own set of headaches.

Now, I just give students a pixi.toml and pixi.lock, and a few commands in the README to get them started. It'll even prevent students from running their projects, adding packages, or installing environments when working on our cluster unless they're on a node with GPUs. My inbox used to be flooded with questions from students asking why packages weren't installing or why their code was failing with errors about CUDA, and more often than not, it was because they didn't allocate any GPUs to their HPC job.

And, as an added bonus, it lets me install tools that I use often with the global install command without needing to inundate our HPC IT group with requests.

So, once again, thank you

> But it's weird to me to see these articles that are so excited about being able to install Python easily when that's been doable with conda for ages. (And conda has additional features not present in uv or other tools.)

I used conda for awhile around 2018. My environment became borked multiple times and I eventually gave up on it. After that, I never had issues with my environment becoming corrupted. I knew several other people who had the same issues and it stopped after they switched away from conda.

I've heard it's better now, but that experience burned me so I haven't kept up with it.

Having the features is not nearly as much use if the whole thing's too slow to use. I frequently get mamba taking multiple minutes to figure out how to install a package. I use and like Anaconda and miniforge, but their speed for package management is really frustrating.

The killer feature of uv for me is much faster uv pip install -r requirements.txt.

> The main thing conda doesn't seem to have which uv has is all the "project management" stuff.

Pixi[1] is an alternative conda package manager (as in it still uses conda repositories; conda-forge by default) that bridges this gap. It even uses uv for PyPI packages if you can't find what you need in conda repositories.

1: https://pixi.sh

Pixi goes a step further, they host mirrors of a lot of the important conda channels!

It's worth noting that uv does not use pip, and it is entirely possible (as noted by uv's existence) to write a new installer that uses PyPI. The conflicts between pip, conda, and any other installers is all about one (or more) installers not having a complete view of the system, typically by having different packaging formats/indices/metadata.

I come from the viewpoint that I don't want my build tool to install my Python for me.

In the same vein, I don't want Gradle or Maven to install my JVM for me.

In JVM land I use SDKMAN! (Yes, that's what the amazingly awesome (in the original sense of awe: "an emotion variously combining dread, veneration, and wonder") concretion of Bash scripts is called).

In Python land I use pyenv.

And I expect my build tool to respect the JVM/Python versions I've set (looking at you Poetry...) and fail if they can't find them (You know what you did, Poetry. But you're still so much better than Pipenv)

I expect my build tool to respect the JVM/Python versions I've set (looking at you Poetry...) and fail if they can't find them

For what it's worth, uv does this if you tell it to. It's just not the default behaviour. Uv and pyenv can easily be used together.

You didn’t mention an important point: speed.

Suppose conda had projects. Still, it is somewhat incredible to see uv resolve + install in 2 seconds what takes conda 10 minutes. It immediately made me want to replace conda with uv whenever possible.

(I have actively used conda for years, and don’t see myself stopping entirely because of non Python support, but I do see myself switching primarily to uv.)

It's true conda used to be slow, but that was mostly at a time when pip had no real dependency resolver at all. Since I started using mamba, I haven't noticed meaningful speed problems. I confess I'm always a bit puzzled at how much people seem to care about speed for things like install. Like, yes, 10 minutes is a problem, but these days mamba often takes like 15 seconds or so. Okay, that could be faster, but installing isn't something I do super often so I don't see it as a huge problem.

The near instant install speed is just such a productivity boost. It's not the time you save, it's how it enables you to stay in flow. In my previous job we had a massive internal library hosted on Azure that took like 5 minutes to install with pip or conda. Those on my team not using uv either resorted to using a single global environment for everything, which they dreaded experiment with, or made a new environment once in the project's history and avoided installing new dependencies like the plague. Uv took less than 30 seconds to install the packages, so it freed up a way better workflow of having disposable envs that I could just nuke and start over if they went bad.

Agreed. When I tried uv first I was immediately taken aback by the sheer speed. The functionality seemed OK, but the speed - woah. Inspiring. So I kept using it. Got used to it now.

In my mind, conda has always been a purpose-specific environment manager for people who live in data science / matplotlib / numpy / jupyter all day every day.

Ruby-the-language is now inseparable from Rails because the venn diagram of the “Ruby” community and the “rails” community is nearly a circle. It can be hard to find help with plain Ruby because 99% of people will assume you have the rails stdlib monkeypatches.

In a similar way, conda and data science seem to be conjoined, and I don’t really see anybody using conda as a general-purpose Python environment manager.

UV doesn’t require an entire duplicated PyPI repository, so there’s that.

True and uv will probbaly never brings non python deps on the table.

But anaconda doesn't do inline deps, isn't a consitent experience (the typical conda project doesn't exist), is it's own island incompatible with most python ecosystem, is super slow, the yaml config is very quirky, and it's very badly documented while having poor ergonomics.

In short, anaconda solves many of those problems but brings other ones on the table.

Also conda does not have a free licence, every organisation with more than 200 employes should pay for it (https://www.datacamp.com/blog/navigating-anaconda-licensing). uv is at date, Apache 2.0.

That is the license for the anaconda package channel, not conda. The page you linked explains that conda and conda-forge are not subject to those licensing issues.

So it's like conda but without getting stuck on "Solving environment: \" for hours?

https://docs.conda.io/projects/conda/user-guide/getting-star...

> To bootstrap a conda installation, use a minimal installer such as Miniconda or Miniforge.

> Conda is also included in the Anaconda Distribution.

Bam, you’ve already lost me there. Good luck getting this approved on our locked down laptops.

No pip compatibility? No venv compatibility? Into the trash it goes, it’s not standard. The beauty of uv is that it mostly looks like glue (even though it is more) for standard tooling.

Well, that's sort of the point though. By leaving behind the "standards" it can add benefits that aren't possible with the standards.