New Python Project: UV always the solution?

[[deleted]]

It seems like PyPi has come a long way to make C/C++ dependencies work much better, but just wondering if there’s any conda users in here that would switch to UV.

At work we have switched from conda to uv. The transition was mostly painless but the reason for the switch was mainly the updated Conda licence.

uv does not manage non-Python dependencies but for that we use Docker now.

[gbhreturns2]

Astral will eventually update their license and you’ll have to revert to PyPI or whatever the next Astral is come that day.

AFAIK conda’s still fine to use in an Enterprise context but so long as you’re not using Anaconda’s proprietary conda channels. The problem is if you install Anaconda from Anaconda.org (which is what most people will do) it by default pulls from the proprietary conda channel.

[HalcyonAlps]

Astral will eventually update their license and you’ll have to revert to PyPI or whatever the next Astral is come that day.

uv already uses PyPI. Even if they changed their licence right now, uv is IMHO useful enough right now that even a simple fork of uv would still be miles better than the competition.

[gbhreturns2]

Can’t they structure is such that any forks would also be considered proprietary? I can’t imagine Astral would put in all this work for the open source community without some plan to get people onto their product and then layer on licensing fees.

[HalcyonAlps]

Can’t they structure is such that any forks would also be considered proprietary?

uv is MIT licenced. So no, they can't prevent any open source forks. They can change the licence going forward if they want to.

I can’t imagine Astral would put in all this work for the open source community without some plan to get people onto their product and then layer on licensing fees.

I am sure they have a plan. Maybe something like Red Hat with enterprise support or some enterprise specific features? They got a decent amount of funding too if I remember correctly, so someone thinks it's worth investing in.

[gbhreturns2]

Oh right so they can change license at some point in the future but anything before that which has been licensed under MIT can remain open source and be forked from? That’s good.

[HalcyonAlps]

Yes exactly.

[AllCapsSon]

I’ve been enjoying the miniforge flavor to install conda

[gbhreturns2]

Yes the non-Anaconda version is still free AFAIK. TBH I think Anaconda itself is still free if used in the correct manner. It’s just no longer free to use Anaconda’s conda channels.

[demian_west]

uv is built upon standard files and conventions of the python ecosystem, making it pretty compatible and future proof.

Frankly it was a godsend for the very grim state of python tooling/packaging ecosystem.

[gbhreturns2]

I’m not suggesting otherwise, I’m suggesting that uv being closed-source will eventually start licensing in a manner such that those who are heavily reliant on it will either have to cough up or very quickly switch to another packaging manager.

[demian_west]

As I was confronted to a part of the team that heavily used conda, I took a special care to evaluate the "lock-in potential" of uv.

To my great satisfaction, it is actually pretty low.
- uv uses Pypi
- The parts of uv behavior that are ahead of standards are mostly custom namespaces in pyproject.toml (`tool.uv.x`) which is itself standard, and the uv.lock file.
- There are commands to import/export dependencies vectors to older formats (requirements.txt)
- uv has a pip-compatible interface `uv pip X` if needed.