121–130 of 206 posts
Earlier quoted context omitted.
Switch to who?
Google's not that broken yet: https://pixi.sh/latest/
I keep reading praise about uv, and every single time I never really understand what problems it addresses. I've got a couple quite big Django projects for which I've used venv for years, and not once have I had any significant issues with it. Speed at times could have been better and I would have liked to have a full dependency list lock file, but that never caused me issues. The only thing that comes to mind is tho…
If you use venv then you have extra steps because you have to explicitly create the venv, then explicitly install the deps there with pip. If your project is designed for a specific python version then developers have to manage that separately (usually pyenv these days).
For people building apps uv replaces venv, pip and pyenv, while being way faster at doing all three of those (you can completely rebuild the virtualenv and install the dependencies from scratch in under a second usually because uv is faster at creating a virtualenv than venv and is very quick at relinking the dependencies from a package cache).
As much as I am glad that it looks like one solution is being more and more accepted as the golden standard, I'm a little disappointed that PDM [0] -- which has been offering pretty much everything uv does for quite some time now -- has been completely overlooked. :( [0] https://pdm-project.org
Man, I’m so jealous of insane praise that uv (and most other astral tools) gets. I don’t think ever seen anything so unanimously lauded around here.
Like with any social media site, you also have to consider the possibility that not all comments are 100% organic.
Earlier quoted context omitted.
You are describing two different problems. Do you want a shapely package that runs on your system or do you want to compile shapely against the GEOS on your system. In case 1 it is up to the package maintainer to package and ship a version of GEOS that works with your OS, python version, and library version. If you look at the shapely page on pypi you'll see something like 40 packages for each version covering most p…
In the first case, how does the package maintainer know which version of libc to use? It should use the one that my system uses (because I might also use other libraries that are provided by my system).
Earlier quoted context omitted.
For value of "years" greater than 1? Node/NPM was a poster child of an ecosystem where projects break three times a week, due to having too many transitive dependencies that are being updated too often.
This argument makes no sense. Your dependencies don't change unless you change them, npm doesn't magically update things underneath you. Things can break when you try to update one thing or another, yes, but if you just take an old project and try and run it, it will work.
It used to prior to npm 5 when lockfiles were introduced (yarn introduced lockfiles earlier).
PyCharm also added uv support in their latest versions. We recently switched to PDM in our company because it worked very well in our tests with different package/dependency managers. Now I am rethinking if we should switch to uv while PDM usage is still not very wide-spread in our company. But PDM works very well, so I am not sure whether to keep using it.
Earlier quoted context omitted.
- uv is aware of your dependencies, you can add/remove development dependencies, create group of development dependencies (test, lint, dev, etc) and add or remove those and only those at will. You can add dependencies and optional dependencies for a project as well, think my_app[cli,standard]. You don't need to have different requirements.txt for each case nor do you need to remove things by hand as you'd do in pip,…
Does this also replace, or work well with tox? We currently use it to run basic CI/local workflows (`tox -e lint` for all linters, `tox -e py310`, `tox -e py312` to run tests suites on chosen interpreters' environments), and to set up a local environment with package installed in-place (so that we can run `myprogram -arg1 -arg2` as if it was installed via `pip`, but still have it be editable by directly editing the r…
For the uninitiated what is the benefit of UV over pip? I've been working with pip for so long now that I barely notice it unless something goes very wrong.
The only advantage over pip is it's faster. But the downside is it's not written in Python. The real point of uv is to be more than pip, though. It can manage projects, so basically CLI commands to edit your `pyproject.toml`, update a lockfile, and your venv all in one go. Unlike earlier tools it implements a pretty natural workflow on top of existing standards where possible, but for some things there are no standar…
I feel for me, at least one nice thing about poetry over uv is, that if I have an issue or feature extension, I can just write my own plugin in pure Python. With uv, I'd need to learn Rust in addition to python/c/c++/etc. I wonder what it would take to get poetry on par with uv for those who are already switching to it? Poetry is definitely very slow downloading multiple versions of packages to determine dependencies…
Dependency resolution is slow because it's computationally very expensive. Because uv is written in Rust the resolution is just much much faster. IIRC they actually reuse the same resolution package that Cargo (Rust's package manager) uses.