21–30 of 45 posts
Earlier quoted context omitted.
Use PDM with the UV backend - this accomplishes this in a much more lightweight and performant way.
Does PDM manage C/Fortran library dependencies? IIRC conda was the only solution for managing both native and python dependencies but I haven't really looked elsewhere. With wheels and the manylinux specifications there's less of a usecase for that, but still could be useful
Why do people use Conda instead of uv?
When I read the uv docs and see other people's examples, I have a hard time understanding how it works for my workflow. It seems I could continue using conda for environment management and only use uv for package installation and it would be much faster, but that also feels a little shaky and potential for error combining the two tools, and since mamba became the default solver conda is pretty fast, even when building a new env from scratch.
It feels like conda and it's ability to have multiple Python versions, with env management built in, gives me more than uv, just without the package installation speed. But I am certainly open to someone explaining uv to me in a way to disprove that
The fact that this exists shows that there is a serious problem in the python ecosystem. I'm sure it solves a real problem, so I'm not knocking the author. It's more of a "state of our industry" problem.
I maintain there is no issue. It's really not hard. conda is a smell for me though. pyenv is all you need. it manages python versions and python virtual environments. you can create and destroy them just as easily as git branches. pyenv + good ol' requirements.txt is really all you need. if your env dictates containers, it's even easier to work with. FROM python:version and done.
Earlier quoted context omitted.
I used to use conda, but have switched entirely to uv now
As someone new to Python: what was ever the appeal of conda that uv doesn't satisfy?
Earlier quoted context omitted.
I maintain there is no issue. It's really not hard. conda is a smell for me though. pyenv is all you need. it manages python versions and python virtual environments. you can create and destroy them just as easily as git branches. pyenv + good ol' requirements.txt is really all you need. if your env dictates containers, it's even easier to work with. FROM python:version and done.
I just install the libraries I need using the operating systems package manager. Works perfectly fine. In development I do use virtualenvs because I need to keep track of which dependencies are required, but in production I just apt-get install.
Earlier quoted context omitted.
I just install the libraries I need using the operating systems package manager. Works perfectly fine. In development I do use virtualenvs because I need to keep track of which dependencies are required, but in production I just apt-get install.
that will 100% come to bite you in the ass one day
I wouldn't recommend it for something with hundreds of dependencies, but I also wouldn't recommend having hundreds of dependencies.
Poetry has messed up packages more often apt ever did, in my use cases. So far using apt as by package manager has failed me exactly zero times.
Earlier quoted context omitted.
that will 100% come to bite you in the ass one day
Probably, but it keeps my dependencies low and packages are automatically updated with backported security patches. So far it has never been an issue, but there has been frustrations when the features aren't available, because the Debian packages aren't the newest versions. I wouldn't recommend it for something with hundreds of dependencies, but I also wouldn't recommend having hundreds of dependencies. Poetry has me…
Earlier quoted context omitted.
Probably, but it keeps my dependencies low and packages are automatically updated with backported security patches. So far it has never been an issue, but there has been frustrations when the features aren't available, because the Debian packages aren't the newest versions. I wouldn't recommend it for something with hundreds of dependencies, but I also wouldn't recommend having hundreds of dependencies. Poetry has me…
If it works, it works. Just be mindful and prepared for the day where it stops working.
Absolutely, but that's true for pretty much all the package managers, for all languages. They all break at some point.
One thing I would note is: Don't install your dependencies with apt in a development environment, you need to have a clean environment to avoid dragging unneeded dependencies into your production environments. That does mean that you need to find the exact version of your dependency in Debian, but it's a good exercise and ensures that you're mindful of your dependencies.
Be mindful, be prepared is good advise, in all aspects of life really.
Why not just call it swamp? It would better describe the python ecosystem mess ;) Jokes aside, this feels very meta: package manager for a package manager for a package manager. Reminds me of the old RFC1925: "you can always add another layer of abstraction". That RFC also says "perfection has been reached not when there is nothing left to add, but when there is nothing left to take away". And as a hpc admin, I'm not…
could you elaborate a bit more on why HPC world is special when it comes to configuring the environment?
I always feel it is a typical problem in software development, to separate operating system env from the application env.
do you use spack / easybuild on your personal computer, for example if you need to install a package that is not part of the distribution?
Earlier quoted context omitted.
I used to use conda, but have switched entirely to uv now
As someone new to Python: what was ever the appeal of conda that uv doesn't satisfy?