4 ms·

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. > Bein

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. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing conda doesn't seem to have which uv has is all the "project management" stuff. Which is fine, it's clear people want that. 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.) 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. The con is that they inherit the limitations of that packaging model (notably the inability to distribute non-Python dependencies separately). That's not to say uv is bad. It seems like a cool tool and I'm intrigued to see where it goes.

necessary 2y ago
The killer feature of uv for me is much faster uv pip install -r requirements.txt.
agent281 2y ago
> 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.
uneekname 2y ago
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.
epistasis 2y ago
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.
- oefrha 2y ago
  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.
  - mufasachan 2y ago
    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.
bitvoid 2y ago
> 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 https://pixi.sh
- greazy 2y ago
  Pixi goes a step further, they host mirrors of a lot of the important conda channels!
matsemann 2y ago
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.
rd11235 2y ago
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.)
- sgt 2y ago
  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.
- BrenBarn 2y ago
  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.
  - mvieira38 2y ago
    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.
BiteCode_dev 2y ago
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.
mkl 2y ago
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.
droelf 2y ago
Thanks for bringing up conda. We're definitely trying to paint this vision as well with `pixi` (https://pixi.sh 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.
- bitvoid 2y ago
  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
optionalsquid 2y ago
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 https://stackoverflow.com/a/74762864
- greazy 2y ago
  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.
- BrenBarn 2y ago
  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).
aragilar 2y ago
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.
wiseowise 2y ago
https://docs.conda.io/projects/conda/user-guide/getting-started.html 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.
- BrenBarn 2y ago
  Well, that's sort of the point though. By leaving behind the "standards" it can add benefits that aren't possible with the standards.
WD-42 2y ago
UV doesn’t require an entire duplicated PyPI repository, so there’s that.
benhurmarcel 2y ago
So it's like conda but without getting stuck on "Solving environment: \" for hours?
EdwardDiego 2y ago
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)
- dagw 2y ago
  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.
zahlman 2y ago
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.)
- zahlman 2y ago
  > 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...)
- BrenBarn 2y ago
  > 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.
E_Bfx 2y ago
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 https://www.datacamp.com/blog/navigating-anaconda-licensing). uv is at date, Apache 2.0.
- BrenBarn 2y ago
  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.
philsnow 2y ago
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.

necessary 2y ago

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

agent281 2y ago

> 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.

uneekname 2y ago

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.

epistasis 2y ago

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.

oefrha 2y ago
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.
- mufasachan 2y ago
  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.

bitvoid 2y ago

> 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 https://pixi.sh

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

matsemann 2y ago

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.

rd11235 2y ago

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.)

sgt 2y ago
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.
BrenBarn 2y ago
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.
- mvieira38 2y ago
  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.

BiteCode_dev 2y ago

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.

mkl 2y ago

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.

droelf 2y ago

Thanks for bringing up conda. We're definitely trying to paint this vision as well with `pixi` (https://pixi.sh 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.

bitvoid 2y ago
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

optionalsquid 2y ago

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 https://stackoverflow.com/a/74762864

greazy 2y ago
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.
BrenBarn 2y ago
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).

aragilar 2y ago

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.

wiseowise 2y ago

https://docs.conda.io/projects/conda/user-guide/getting-started.html 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.

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

WD-42 2y ago

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

benhurmarcel 2y ago

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

EdwardDiego 2y ago

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)

dagw 2y ago
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.

zahlman 2y ago

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.)

zahlman 2y ago
> 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...)
BrenBarn 2y ago
> 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.

E_Bfx 2y ago

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 https://www.datacamp.com/blog/navigating-anaconda-licensing). uv is at date, Apache 2.0.

BrenBarn 2y ago
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.

philsnow 2y ago

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.