4 ms·

Just a few months back I said I would never use uv. I was already used to venv and pip. No need for another tool I thought. I now use uv for everything Python.

• espdev 1y ago
  > Just a few months back I said I would never use uv. I was already used to venv and pip. No need for another tool I thought Really? :) requirements.txt is just hell and torture. If you've ever used modern project/dependency management tools like uv, Poetry, PDM, you'll never go back to pip+requirements.txt. It's crazy and a mess. uv is super fast and a great tool, but still has roughnesses and bugs.
  • pinoy420 1y ago
    [dead]
  • aequitas 1y ago
    Pip-tools+requirements.txt helped me survive the past few years. I also never thought I needed uv, but after all the talk about it I gave it a spin and never want back. It’s just so blazing fast en convenient.
  • _Algernon_ 1y ago
    pip also works with pyproject.toml. Sticking with requirements.txt is a self-imposed constraint.
  • kortex 1y ago
    We use uv to compile requirements.txt from pyproject.toml to get the locked versions. # Makefile compile-deps: uv pip compile pyproject.toml -o requirements.txt compile-deps-dev: uv pip compile --extra=dev pyproject.toml -o requirements.dev.txt
    • espdev 1y ago
      What for? Support legacy CI/CD pipelines or something like that? uv.lock already contains locked versions of all dependencies plus a lot of other needed metadata.
      • halfcat 1y ago
        > What for? Support legacy CI/CD pipelines Yes. Azure, for instance, looks for requirements.txt if you deploy a web app to Azure App Service. If you’re doing a code-based deployment, it works really well. Push to GitHub, it deploys. You can of course do a container-based deployment to Azure App Service and I’d assume that will work with uv.
      • esseph 1y ago
        "legacy CI/CD pipelines" Damn I'm getting old
        • espdev 1y ago
          Maybe. I've been programming in C++ and also in Python for almost 20 years. And I'm just happy that Python has finally started to have convenient tools for packaging and dependency management. I thought everything was cursed here, and I just hate requirements.txt. It seems they were able to overcome this curse.
• psychoslave 1y ago
  I wonder how it compares with something more green generalist like "mise", to which I migrated after using "ASDF" for some time.
  • wrboyce 1y ago
    I use both! uv installed globally with mise, and uv tools can then be managed via “miss use -g pipx:foo”.
    • icedchai 1y ago
      Same! I recently set up some dev environments with mise. My old ones are still using poetry, the new ones have uv. uv is incredibly snappy. It's like night and day!
  • codethief 1y ago
    Similarly to the sibling I also use both. I let mise manage my uv version (and other tools) and let uv handle Python + PyPI Packages for me. Works great! There's also some additional integration which I haven't tried yet: https://mise.jdx.dev/mise-cookbook/python.html#mise-uv https://mise.jdx.dev/mise-cookbook/python.html#mise-uv
  • varikin 1y ago
    Think of uv more as like npm or other thing like that. The new Python pyproject.toml is similar package.json. It defines the project description, list of dependencies, and other hooks. Uv is a package/project tool using pyproject.toml. It is easy to manage dependencies, build and publish to PyPi, add hooks to run tests, linters, or whatever, again much like package.json. It also manages the virtualenv automatically, though you can manage it yourself.
  • elbear 1y ago
    Thanks for mentioning mise. I'm more interested in it for the task running feature. I couldn't figure out how to have shell scripts in Justfile, so I gave up on it.
    • 1y ago
• yjftsjthsd-h 1y ago
  > Each user had 10GB of storage allocated and pip's cache was taking up a ton of space & not letting me change the location properly. Switched to uv and everything just worked Is it better about storage use? (And if so, how? Is it just good at sharing what can be shared?)
  • fsh 1y ago
    uv hardlinks identical packages, so adding virtual envs takes up very little space.
    • snerbles 1y ago
      Unless you cross mount points, which uv will helpfully warn about.
      • codethief 1y ago
        In those situations, have you had a any luck using UV_LINK_MODE=symlink? I eventually had to resort to `copy` mode because it seemed the folder names (hashes) uv created in the package cache were not fully deterministic. So sometimes my cache volume would change and my Docker build would break. :\
  • kissgyorgy 1y ago
    There is a global cache for all installed packages in the user home cache dir.
  • _lvbh 1y ago
    Both pip and uv cache packages to ~/.cache. Uv lets you change it to /tmp and symlink instead of copying
    • esseph 1y ago
      Note: /tmp will take awhile to get rid of, but it's definitely on the chopping block. I'd avoid workflows that lean on it, if anything else for security's sake.
• tetha 1y ago
  For me, the big key was: uv is so much easier to explain and especially use - especially for people who sometimes script something in python and don't do this daily. pip + config file + venv requires you to remember ~2 steps to get the right venv - create one and install stuff into it, and for each test run, script execution and such, you need to remember a weird shebang-format, or to activate the venv. And the error messages don't help. I don't think they could help, as this setup is not standardized or blessed. You just have to beat a connection of "Import Errors" to venvs into your brain. It's workable, but teaching this to people unfamiliar with it has reminded me how.. squirrely the whole tooling can be, for a better word. Now, team members need to remember "uv run", "uv add" and "uv sync". It makes the whole thing so much easier and less intimidating to them.
  • robertlagrant 1y ago
    This is similar to things like poetry (poetry run ..., poetry add, poetry install), but yeah. Does look nice.
• _vya7 1y ago
  I remember using pip and venv back in like 2009. Last time I checked, maybe 5 or 10 years ago, the recommendation of the community was generally to just use Docker instead of all these tools. Did that not catch on?
  • unclad5968 1y ago
    The advice seems to change every year. For a while it was venv, then pipenv, poetry, docker, and now uv. Maybe the ecosystem will settle on that but who knows.
    • AlphaSite 1y ago
      I mean docker is orthogonal to package manager. It makes it easier to deploy but none of the other thing also have managers do are relevant.
  • lmm 1y ago
    Docker was always a workaround to Python not having a non-awful dependency manager. uv is that non-awful dependency manager, and I expect in the long term it will reduce the use of Docker.
  • dagw 1y ago
    Docker solves a different problem. Docker is a way to basically ship your whole OS off to another machine. You still have to have a way to install the right version of python and all the python libraries you need inside the Docker container, and uv is great for this. Secondly Docker only solves a subset of problems. It's fine if you're developing a server that you will be deploying somewhere. It's inconvenient if you're developing an end user application, and it's completely useless if you're developing a library you want people to be able to install.
• ed_elliott_asc 1y ago
  I came here to comment that I don’t see any reason to bother - that’s for the comment, I will try it now!
• tomjakubowski 1y ago
  The absolute killer feature for me of uv is that it's still compatible with all of my old venv-based workflows. Just run `uv venv`.
  • deleted 1y ago
    [deleted]
  • level09 1y ago
    Unfortunately uWSGI (one of the most important libraries) is fundamentally incompatible with uv. had to roll back all my apps that use custom uWSGI for that reason.
    • iFreilicht 1y ago
      Could you explain how? Does it do something funky in the venv that uwsgi doesn't understand?
    • tadaima 1y ago
      I am using uwsgi with uv. This is not to say the problems you are facing are not real, but it cannot be a 'fundamental incompatibility' if it is working in my case. Here is an example of a CLI invocation I am using for quick testing: -- uv run uwsgi --socket 0.0.0.0:8080 --protocol=http -w foo.app:server --processes 2 --threads 2 --stats 0.0.0.0:9191 --
• oofbey 1y ago
  I love uv. The one gotcha I'll warn people about is: don't touch uvx. I've lost an embarrassing number of hours or days trying to figure out why nothing works properly or makes sense when I tried to run things with uvx. I guess I understand why it's there, but I think it's a built-in foot-gun and not well documented. But if you stay away from it, things work great.
  • maleldil 1y ago
    uvx is fine. I use it to run executable packages all the time. What is your problem with it?
  • jsmeaton 1y ago
    What issues are you having with uvx? It replaces tools like pipx that set up implicit venvs to run specific tools. Works great for me.
  • nirv 1y ago
    I suppose you didn't accompany the command `uvx` with the necessary `--with=` arguments[1] for each dependency. [1] https://docs.astral.sh/uv/guides/tools/#commands-with-plugins https://docs.astral.sh/uv/guides/tools/#commands-with-plugin...
• mistrial9 1y ago
  similar story recently with an experimental repo that starts with "its so easy, just $uv a b c" .. under the hood it implies a lot of redundancies? but true enough it worked fine and trouble-free too, on a standard GNU-Debian-Ubuntu host
• bmitc 1y ago
  What has been holding me back on uv is my experience with Ruff. Ruff claims "Drop-in parity with Flake8, isort, and Black", but that is simply not true. At least for isort, Ruff only re-implemented what they wanted and then ask you to use Ruff to call out to the old isort tool if there's a feature or setting that's missing in the Ruff re-implementation. So what's the point? Ruff just partially re-implemented many existing different tools and added some new ones. So using Ruff actually increases the amount of tools, yet again, you're having to use because of this and it also not doing everything that Pylint does. For moving to uv, I haven't heard a good story for what uv provides over Poetry rather than "is fast". The only unique thing that I am currently aware of is that uv can install Python itself, which gets rid of tools like Pyenv. I'm interested because of that, but "is fast" isn't enough of a reason.
  • Hasnep 1y ago
    My experience is that ruff reimplemented 99% of the most popular features of black, isort, flake8, pylint, etc. and then added 10000% more features on top, that feels like a fair tradeoff to me. I've converted multiple large Python codebases to ruff, and each time I just configure ruff as close to the previous tools as possible, then reformat the entire codebase with ruff and remove all the previous tools. The speed increase when linting alone is worth the minor formatting changes to me. If you really insist on keeping isort's sorting then you could at least replace black and pylint, which would reduce the total number of tools by one.
  • projectdelphai 1y ago
    I think you're underestimating how "fast" uv really is. It's night and day different. The sentence that got me to switch and I echo still was: "uv is so fast, I sometimes don't even think it's actually doing anything". The first time I used it, I had to actually double check if uv actually was working and installing the packages that it was saying it was. There's a lot of reasons I've heard not to use it that kind of (not really) make sense (you don't want another package manager, you're happy with just base pip, etc). But if you're already using poetry, you really should just switch. uv is just poetry but without any waiting. Even your most complicated projects should be able to switch within a day. The only reason I took any time was having to restructure my docker containers to work with uv instead of poetry. And that's mostly with my inexperience with docker, not because uv is complicated.
• PeterStuer 1y ago
  Just made the switch myself. Was far easier and smoother than I expected.