uv, venv, conda, brew, deb, nix, guix, chocolatey, containers, jails... One day we will finally find the ONE solution to this problem.
call it: one
A year of uv: pros, cons, and should you migrate
311–320 of 401 posts
Re: A year of uv: pros, cons, and should you migrate
#312Earlier quoted context omitted.
Naive take. https://gwern.net/holy-war counsels that, in fact, becoming the One True Package Manager for a very popular programming language is an extremely valuable thing to aim towards. This is even outside of the fact that `uv` is backed by a profit-seeking company (cf https://astral.sh/about ). I'm all for people choosing what works best for them, but I'm also staunchly pro-arguing over it.
> becoming the One True Package Manager for a very popular programming language is an extremely valuable thing For companies. Which is why when random people start acting like it’s important, you have to wonder why it’s important to them. For example, being a corporate shill. Or so deep in coolaid you can’t allow alternative opinions? Hm? It’s called an echo chamber.
Why on earth would it be only important for companies?
Re: A year of uv: pros, cons, and should you migrate
#313Earlier quoted context omitted.
Any flow that does not state checksums/hashsums is not ready for production and all but beautiful. But I haven't used uv yet, so maybe it is possible to specify the dependencies with hashsums in the same file too? Actually the order of import statement is one of the things, that Python does better than JS. It makes completions much less costly to calculate when you type the code. An IDE or other tool only has to chec…
> Why not have smaller venvs for separate projects? Because they are annoying and unnecessary additional work. If I write something, I won't know the dependencies in the beginning. And if it's a personal tool/script or even a throwaway one-shoot, then why bother with managing unnecessary parts? I just manage my personal stack of dependencies for my own tools in a giant env, and pull imports from it or not, depending…
Well, if generating a lock file and installing dependencies is "unnecessary" then you obviously don't have any kind of need to be production ready project. Any project serious about managing its dependencies will mandate hashsums for each dependency, to avoid things having issues a week or a month later, without change to the project.
If you do have a project that needs to manage its dependencies well and you still don't store hashsums and use them to install your dependencies based on them, then basically you forfeit any credibility when complaining about things going wrong with regard to bugs happening or changed behavior of the code without changing the code itself and similar things.
This can be all fine, if it is just your personal project, that gets shit done. I am not saying you must properly manage dependencies for such a personal project. Just not something ready for production.
I for one find it quite easy to make venvs per project. I have my Makefiles, which I slightly adapt to the needs of the project and then I run 1 single command, and get all set up with dependencies in a project specific venv, hashsums, reproducibility. Not that much to it really, and not at all annoying to me. Also can be sourced from any other script when that script uses another project. Could also use any other task runner thingy, doesn't have to be GNU Make, if one doesn't like it.
Re: A year of uv: pros, cons, and should you migrate
#314Earlier quoted context omitted.
Pinning deps is a good thing, but it won't necessarily solve the issue of transitive dependencies (ie: the dependencies of requests itself for example), which will not be pinned themselves, given you don't have a lock file. To be clear, a lock file is strictly the better option—but for single file scripts it's a bit overkill.
1 file, 2 files, N files, why does it matter how many files? Use a lock file if you want transitive dependencies pinned. I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing.
For N scripts, you will need N lock files littering your directories and then need venvs for all of them.
Sometimes, the lock files can be larger than the scripts themselves...
Re: A year of uv: pros, cons, and should you migrate
#315Earlier quoted context omitted.
Any flow that does not state checksums/hashsums is not ready for production and all but beautiful. But I haven't used uv yet, so maybe it is possible to specify the dependencies with hashsums in the same file too? Actually the order of import statement is one of the things, that Python does better than JS. It makes completions much less costly to calculate when you type the code. An IDE or other tool only has to chec…
Why did they do that? Why not have smaller venvs for separate projects? What's a 'project'? If you count every throw away data processing script and one off exploratory Jupyter notebook, that can easily be 100 projects. Certainly before uv, having one huge venv or conda environment with 'everything' installed made it much faster and easier to get that sort of work done.
In what kind of scope are these data processing scripts? In some kind of pipeline used in production I very much would expect them to have reproducible dependencies.
I can understand it for exploratory Jupyter Notebook. But only in the truly exploratory stage. Say for example you are writing a paper. Reproducibility crisis. Exploring is fine, but when it gets to actually writing the paper, one needs to make ones setup reproducible, or lose credibility right away. Most academics are not aware of, or don't know how to, or don't care to, make things reproducible, leading to non-reproducible research.
I would be lying, if I claimed, that I personally always set up a lock file with hashsums for every script. Of course there can be scripts and things we care so little about, that we don't make them reproducible.
Re: A year of uv: pros, cons, and should you migrate
#316Earlier quoted context omitted.
As a long time Pythonista I was going to push back against your suggestion that Python didn't have much momentum until recently, but then I looked at the historic graph on https://www.tiobe.com/tiobe-index/ and yeah, Python's current huge rise in popularity didn't really get started until around 2018. (TIOBE's methodology is a bit questionable though, as far as I can tell it's almost entirely based on how many search…
Tiobe is garbage. I remember Python making waves since 2005 with Google using it and such.
From what I can tell it wasn't as prominent as it has been recently, with being a popular pick for random projects that weren't just gluing things together. The big companies that used it were perfectly happy specializing the interpreter to their use case instead of upstreaming general improvements
Re: A year of uv: pros, cons, and should you migrate
#317Can anyone explain to a non-python developer why python infrastructure is so much broken around the version management? It looks to me that every new minor python release is a separate additional install because realistically you cannot replace python 3.11 with python 3.12 and expect things to work. How did they put themselves in such a mess?
Python code rarely breaks between minor version releases in my experience. Python 3.5 introduced the `async` keyword (PEP 492), and Python 3.7 changed `StopIteration` handling in generators (PEP 479).
Re: A year of uv: pros, cons, and should you migrate
#318Like 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…
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.
Re: A year of uv: pros, cons, and should you migrate
#319Author here. A.m.a
Great overview thanks I just reviewed uv for my team and there is one more reason against it, which isn't negligible for production-grade projects: Github Dependabot doesn't handle (yet) uv lock file. Supply chain management and vulnerability detection is such an important thing that it prevents the use of uv until this is resolved (the open github issue mentions the first quarter of 2025!)
uv export?
Re: A year of uv: pros, cons, and should you migrate
#320A scenario for "don't use uv" I hope none of you encounter: many nvidia libraries not packaged up in something better like torch. Here's just one example, nemo2riva, the first in several steps to taking a trained NeMo model and making it deployable: https://github.com/nvidia-riva/nemo2riva?tab=readme-ov-file#... before you can install the package, you first have to install some other package whose only purpose is to…
Surely you can just manually add their index, right?
yes, but if you’re not in their carefully directed “nemo environment” the nemo2riva command fails complaining about some hydra dependency. and on it goes…