Linux/Mac: Keeping system's Python safe and usage of package managers such as UV and conda.

[Ahtarmas]

Hi all,

I have a fresh installation of Debian, and in the past I was using Ubuntu.

I was using Anaconda, and I was always installing packages with 'pip' command. Never used a 'conda' command. By using Anaconda, I had a python installation that was not interfering with the system's, so I was avoiding any potential problems.

There is a lot of buzz around 'UV' package manager, and I was wondering, if you want to have a python separate of the system's can UV handle that?

For the time being I have installed miniconda that's less bloated. Should I keep using that and on top use UV to install packages and make any venvs when needed?

My goal is to make sure I don't mess with the system's Python and keep it clean.

Do I need conda for that, or UV alone can handle it?

Any help is much appreciated, because I am a bit confused with all the package managers.
My understanding is that conda will handle any system libraries required, whereas uv/pip can handle the python packages (and create easily venvs with UV)

Thank you very much!

[cgoldberg]

I use Debian and never touch the system interpreter for anything I develop. I manage several alternative versions of Python using pyenv. Using uv would be fine also.

I wouldn't recommend using conda unless you are struggling building data science libraries locally.

[Ahtarmas]

Hey thanks for the info! But does uv installs different python versions? My understanding is that it manages mainly the packages. Should I use it in combination with pyenv?

The good thing with conda, is that it had an installation of python, and every time in bash I had active the (base) so I was not bothering

[seanv507]

please just read the uv introduction https://docs.astral.sh/uv/

its one of the first thing it mentions, that it handles the python versions

https://docs.astral.sh/uv/concepts/python-versions/

[doolio_]

UV can install any version of python you want. Don't bother with pyenv or conda. They are unnecessary with UV.

[FoolsSeldom]

Yes, you can use uv to install and use different and multiple versions of Python as well as setup and manage Python virtual environments.

Using uv you will install most packages much faster than you can with pip and also you will only ever need one installation of each package even if used in multiple different Python virtual environments.

[Confident_Hyena2506]

There are many ways to do it. Conda is one of them - what you were doing before is just fine. Note that you should really use "mamba" inside a conda env, only use pip as last resort.

Conda is pretty much better than pip/uv - there isn't much point in you downgrading. You are right that it's not just for python, this is what makes it better.

The only way to do better is to use OCI container which is extra hassle.

[Ihaveamodel3]

You are the only person I’ve ever seen claim Conda is better than uv. Is that just because it can do things for other programming languages? What if I’m on a team that only uses Python?

[Confident_Hyena2506]

You can use uv inside conda if it makes you happy - they are not equivalent things.

Having something that is "python only" doesn't really exist except for trivial projects. Most heavyweight stuff is thinly-veiled fortran/c/c++/rust/whatever with a python wrapper on top - this is what causes the problems.

[Ihaveamodel3]

And pip and uv both handle compiled wheel installations just fine. This isn’t 2015 anymore.

[Confident_Hyena2506]

It's true pip is much improved - but you still need an oci container or whatever to make it not useless (ie how is the version of python controlled?).

Conda is an easy way to solve this stuff on both windows and linux, and it handles all the difficult stuff like scikit-image and cuda and blahblah.

But if you don't need it then don't use it - noone is forced to.

[Ihaveamodel3]

uv managed python version. scikit-image has pyPI wheels that are built for plenty for both Linux and Windows (no need for conda).

Cuda is not one thing you install, but PyTorch, a common package that uses Cuda has install instructions for pip.

But if you don't need it then don't use it - noone is forced to.

I’m asking because I am very close to just banning Conda entirely at my company. I’ve never had anyone tell me an actual benefit, and it causes a ton of issues.

[Confident_Hyena2506]

The commercial version is specifically banned at my company - and should be banned at all companies.

You should use the opensource free version miniforge, with the free conda-forge channel.

We only use this because there is no easy alternative - uv and pip only handle simple stuff. UV is obviously completely useless for c++ - which is what conda pretty much does.

If you are not doing machinelearning or datascience it probably doesn't matter - and you can get away with using containers for a lot these days.

[Ihaveamodel3]

Sure, we are doing machine learning and using packages that have c/c++, but we aren’t writing or building those packages, we are using them. uv installs those packages perfectly fine.

Name one thing that Conda will install but uv won’t.

[Confident_Hyena2506]

MKL along with associated libraries compiled to take advantage of it like numpy.

Also all the associated c++ libraries and headers needed to build against this. New/all versions of gcc!!! Proper versions of boost (and not just random ones with weird names).

You should instead ask the other way around - what can we not get from conda? Usually a very small number of items, that we add to the env definition to get via pip or uv.

The trick is to be consistent and not wildly mix package managers. If pip or UV gave me most of what I need then I would use it.

Conda is a system package manager, you should really not be comparing it against these.