15 ms·

Switching from Pyenv to Uv

351 points by harryvederci 2y ago

oblio 2y ago
How does this compare to Mise: https://mise.jdx.dev/lang/python.html https://mise.jdx.dev/lang/python.html ?
- claytonjy 2y ago
  mise is higher level. i use it to install uv in projects with other non-python dependencies (helm, terraform, npm), which i also install with mise. Then all the python dependencies are managed with uv. For a non-python project which needs a python-based CLI tool, i’m not sure if i’d use mise or uv (uvx).
xucian 2y ago
has anybody doing complex projects achiever success with uv completely replacing pyenv, and had mostly pros and few or no cons? I'm very comfortable with pyenv, but am extremely open to new stuff
- emgeee 2y ago
  I've used uv to work on the feast feature store project to great success
- NeutralForest 2y ago
  Sure, I've basically replaced pyenv, pyenv-virtualenv, poetry; with uv. I can't think about cons personally, though you might need to dig into the docs at times.
- ath3nd 2y ago
  I worked in a large-ish org where 20+ python projects, their CI/CD pipelines and their docker images were migrated from `pyenv` + `.python-version` + `requirements.txt` to `uv` in basically a single day. If you are comfortable with `pyenv`, the switch to `uv` is basically a walk in the park. The benefit is the speed + the predictable dependencies resolution.
  - ttyprintk 2y ago
    Astral ships a Docker image that provides their tox-uv. I saw maybe a 3x speed up setting up environments.
- rat87 2y ago
  I don't know how complex your project is but I moved my previous work from pyenv to rye(UV and rye have merged, most work is being done on uv, today I'd probably use UV) And am currently trying to move current work to UV. The problems seem to be possibility of unknown breakage for unknown users of the old project not any known technical issue. I'd highly reccomend UV. Its just easier/more flexible. And it downloads third party pre compiled python builds instead of the extra time and complexity to get it compiling locally. Its much nicer especially when maintaing an environment for a team that just works without them having to know about it One downside of UV is that unlike pyenv and rye it doesn't shim python. Pyenv shim did give me some trouble but rye simples shim didn't. The workaround is to run stuff with uv run x.py instead of python x.py
  - ttyprintk 2y ago
    `uv tool install` will create shims in .local/bin
    - rat87 2y ago
      Sorry I meant shims for python. I think I mentioned installing tools
  - xucian 2y ago
    thanks, running "uv run x.py" is a relevant downside for me, but you definitely brought me closer to actually looking into it. I'm about to sell a project template and it'd look good if I use a newer tool (as long as I'll make sure it's stable and resilient, the latter being a bit hard to estimate, thus my post)
- __mharrison__ 2y ago
  Teaching a course for a corporate client this week for data scientists. The first day (of five) we covered uv. Minds blown. "Course was worth it just for uv"
  - xucian 2y ago
    thanks, this encourages me to explore it more
theogravity 2y ago
Is there a guide for how to use uv if you're a JS dev coming from pnpm? I just want to create a monorepo with python that's purely for making libraries (no server / apps). And is it normal to have a venv for each library package you're building in a uv monorepo?
- BiteCode_dev 2y ago
  If the libraries are meant to be used together, you can get away with one venv. If they should be decoupled, then one venv per lib is better. There is not much to know: - uv python install <version> if you want a particular version of python to be installed - uv init --vcs none [--python <version>] in each directory to initialize the python project - uv add [--dev] to add libraries to your venv - uv run <cmd> when you want to run a command in the venv That's it, really. Any bonus can be learned later.
  - NeutralForest 2y ago
    There's also workspaces (https://docs.astral.sh/uv/concepts/projects/workspaces/ https://docs.astral.sh/uv/concepts/projects/workspaces/) if you have common deps and it's possible to act on a specific member of the workspace as well.
    - BiteCode_dev 2y ago
      That's one of the bonus I was thinking about. It's nice if you have a subset of deps you want to share, or if one dep is actually part of the monorepo, but it does require more to know.
  - new_user_final 2y ago
    uv sync if you clone a github repo
    - BiteCode_dev 2y ago
      uv run in the freshly cloned repo will create the venv and install all deps automatically. You can even use --extra and --group with uv run like with uv sync. But in a monorepo, those are rare to use.
unsnap_biceps 2y ago
Uv in script mode has made me love python again.
bnycum 2y ago
I decided to give uv a shot on my new machine over pyenv and I've been enjoying it. Just last week I had to generate out 90 slides from some data last minute. Quickly created a project added in my dependencies (pandas, matplotlib, python-pptx), then crunched out some code. Absolutely zero friction with a much easier to use set of commands in my opinion.
rsyring 2y ago
15 year Python dev who usually adopts tooling slowly. Just do it, uv's absolutely worth it. I also use mise with it, which is a great combination and gives you automatic venv activation among other things. See, among other mise docs related to Python, https://mise.jdx.dev/mise-cookbook/python.html https://mise.jdx.dev/mise-cookbook/python.html See also a Python project template I maintain built on mise + uv: https://github.com/level12/coppy https://github.com/level12/coppy
- NeutralForest 2y ago
  I used to install Python through mise but now I just use uv tbh.
  - rsyring 2y ago
    Similar. But we get other benefits through mise, like tasks and other tool installs (e.g. Terraform). So we still use them together.
    - NeutralForest 2y ago
      That's fair, it's also nice if you have a backend in Python and a frontend in JS since mise also handles node.
      - rsyring 2y ago
        Forgot about that! Yes, another significant benefit of why we use mise. In particular, we use flask-vite and it's so nice to be able to have the right version of Node specified in the same management system as we specify the Python version. This solved a not insignificant amount of angst around FE development for me personally since I spend most of my time in the BE. It's not like it was insurmountable before. But now, with mise, it's in that "just works" category for me.
        NeutralForest 2y ago
rullopat 2y ago
[flagged]
- fwip 2y ago
  I think you might have your dates confused. Pyenv was first released about 8 years ago.
- alexjplant 2y ago
  You're being downvoted (for snark presumably) but you have a point. During my tenures as a Python developer I've had to deal with pip, pipx, venv, pipenv, setuptools, conda, and poetry. I'd not heard of pyenv or uv until this thread (or maybe I've touched pyenv and got it confused with one of the 7 other tools I mentioned) and I'm sure there are other dependency/environment management tools floating around that I missed. Now that I'm back to Go it's `go get` with some mise tasks. It's a serious breath of fresh air. The Python ecosystem probably won't ever catch up to npm when it comes to cranking out shiny new things but it's definitely more bleeding edge than a lot of other languages.
  - turtlebits 2y ago
    In the past 10 years, virtualenv and pip have been perfectly fine for me. They still are. I ignored any new tooling. uv is great so far, I did run into a hiccup where moving from pip with a requirements.txt file to uv slowed a CI pipeline way down that I had to revert.
    - __mharrison__ 2y ago
      Odd that it slowed down. I wondered what happened. For me and my clients, uv has been 2-4 orders of magnitude faster.
  - rat87 2y ago
    The reason there have been so many is because the standard included tools (pip, venv) are not great. And others could still use improvements. Venv and setup tools aren't really package managers. Pipx is only meant for installing Dev tools per user (in isolated Venvs). pyenv does something a bit different from those tools you listed(maybe it'd part of cones I haven't tried it). Its not a dependency manager its a python version manager like nvm (node version manager). It helps you manage downloading and compiling python from source and it let's you specify python version in a .python-version file and provides a shim to find the right python for a project(compiling it if its not already available). I tried pipenv and despite being hyped for it, it had a lot of issues. Then I tried poetry which seemed much better but was still sort of slow and got stuck updating lock files sometimes. I haven't even tried pdm. Or various conda package managers since its mainly used by scientists with lots of binary dependency needs. Then ~~uv~~ rye came along and seemed to fix things. It replaced pip+pip tools/pipenv/poetry. Also replaced pipx(install python tools in isolated venvs then add it to users ./local/bin). Also replaced pyenv but instead of compiling python which takes a while and can be troublesome it downloads portable builds https://astral.sh/blog/python-build-standalone https://astral.sh/blog/python-build-standalone (which do have some downsides/compatibility issues but are usually better then compiling python). It was also written in rust so avoided circular venv issues that sometimes come with installing python packages since it had a self contained binary(plus some shims). Then UV came along, the projects merged and most development is happening in uv. Despite the rye-> switch most things are pretty similar and I feel a lot of excitement towards it. The one big difference is there's no shims to automatically call the right python for a project from UV. Instead you need to run uv run script.py Astral the guys behind UV took over the independent python builds and have also built the most popular python formater/linter these days - ruff (also written in rust, also fast they're also looking into adding a better type checker for python type hints). I'd reccomend trying it for your next project I think it could become the defacto packaging/version tool for python
quickslowdown 2y ago
I highly, highly recommend uv. It solves & installs dependencies incredibly fast, and the CLI is very intuitive once you've memorized a couple commands. It handles monorepos well with the "workspaces" concept, it can replace pipx with "uv tool install," handle building & publishing, and the docker image is great, you just add a FROM line to the top and copy the bin from /uv. I've used 'em all, pip + virtualenv, conda (and all its variants), Poetry, PDM (my personal favorite before switching to uv). Uv handles everything I need in a way that makes it so I don't have to reach for other tools, or really even think about what uv is doing. It just works, and it works great. I even use it for small scripts. You can run "uv init --script <script_name.py>" and then "uv add package1 package2 package3 --script <script_name.py>". This adds an oddly formatted comment to the top of the script and instructs uv which packages to install when you run it. The first time you run "uv run <script_name.py>," uv installs everything you need and executes the script. Subsequent executions use the cached dependencies so it starts immediately. If you're going to ask me to pitch you on why it's better than your current preference, I'm not going to do that. Uv is very easy to install & test, I really recommend giving it a try on your next script or pet project!
- midhun1234 2y ago
  Can confirm this is all true. I used to be the "why should I switch" guy. The productivity improvement from not context switching while pip installs a requirements file is completely worth it.
- baby_souffle 2y ago
  I didn't know that UV would now edit the script for you. That is just icing on the cake! For the curious, the format is codified here: https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/
- scribu 2y ago
  The install speed alone makes it worthwhile for me. It went from minutes to seconds.
  - BoorishBears 2y ago
eikenberry 2y ago
Maybe this one will finally be adopted as the official package manager for Python? Only 20 years late, but it would be a nice development.
- 0cf8612b2e1e 2y ago
  Pfft. Pull the other one. The PSF hates the idea of dealing with something so icky. I have been pretty pleased with uv, but I am continually worried about the funding model. What happens when the VC starts demanding a return?
  - __MatrixMan__ 2y ago
    We fork it. Whatever carrot the VC's dangle can be chased by the handful who care, and the rest of us can continue using the important part.
    - Kwpolska 2y ago
      Ah, so that's why it's written in Rust. Less people who care about Python packaging are capable of forking it.
      - __MatrixMan__ 2y ago
        I guess this is a joke but honestly I think that Python -> Rust is a pretty strong one. I'd bet that the sort of person who is maintaining packaging for a bunch of Python users would like an opportunity to learn Rust on the job. I would.
        eikenberry 2y ago
        IMO this is unlikely. Rust and Python have very little in common.
- wirHga 2y ago
  Please not. Python core is suffering from corporate capture and ruins everything it touches. The PSF would probably dig up some old posts from the uv authors, defame them, take the code and make it worse.
vslira 2y ago
I'm using exclusively uv for personal projects - and small prototypes at work - and I can't recommend it enough. Uv makes python go from "batteries included" to "attached to a nuclear reactor"
- scratchyone 2y ago
  i’ve started slipping uv into production work projects along with an auto generated requirements.txt for anyone who doesn’t wanna use uv. hoping i can drive adoption on my team while still leaving an alternative for people who don’t wanna use it
  - globular-toast 2y ago
    You mean `uv pip compile pyproject.toml > requirements.txt`?
kubav027 2y ago
I am pretty happy with poetry for near future. I prefer using python interpreters installed by linux package manager. In cloud I use python docker. Poetry recently added option to install python too if I changed my mind. I have already setup CI/CD pipelines for programs and python libraries. Using uv would probably save some time on dependency updates but it would require changing my workflow and CI/CD. I do not think it is worth the time right now. But if you use older environments without proper lock file I would recommend switching immediately. Poetry v2 supports pyproject.toml close to format used by uv so I can switch anytime when it would look more appealing. Another thing to consider in long term is how astral tooling would change when they will need to make money.
- js2 2y ago
  > I prefer using python interpreters installed by linux package manager. uv will defer to any python it finds in PATH as long as it satisfies your version requirements (if any): https://docs.astral.sh/uv/concepts/python-versions/ https://docs.astral.sh/uv/concepts/python-versions/ It also respects any virtual environment you've already created, so you can also do something like this: /usr/bin/python3 -m venv .venv .venv/bin/pip install uv .venv/bin/uv install -r requirements.txt # or .venv/bin/uv run script ... It's a very flexible and well thought out tool and somehow it manages to do what I think it ought to do. I rarely need to go to its documentation. > Using uv would probably save some time on dependency updates but it would require changing my workflow and CI/CD. I found it very straightforward to switch to uv. It accommodates most existing workflows.
- irjustin 2y ago
  I'm pretty much with you and still trying to figure out why I want to switch away from pyenv+poetry. I get that uv does both, but I'm very happy with pyenv+poetry combo. Old baggage, but I came from the rvm world which attempted to do exactly what uv does, but rvm was an absolute mess in 2013. rbenv+bundler solved so many problems for me and the experience was so bad that when I saw uv my gut reaction was to say "never again". But this thread has so many praises for it so one day maybe i'll give it a try.
  - 2y ago
BiteCode_dev 2y ago
Note that despite the title, the author is not switching from pyenv to uv, but from pip, pyenv, pipx, pip-tools, and pipdeptree to uv, because uv does much more than pyenv alone. It replaces a whole stack, and does each feature better, faster, with fewer modes of failure.
moltar 2y ago
I wasn’t able to figure how to make a uv installed python version a global when “python” is called, at least in the current shell, as I need it in CI.
- kstrauser 2y ago
  That feature's in preview now. You can run it like: uv python install --preview --default 3.13 and then you get Python 3.13 whenever you run `python` outside of an environment that declares something else.
  - moltar 2y ago
    Thank you!! Will try it tomorrow.
    - kstrauser 2y ago
      You bet. I was so happy to find that!
  - leejoramo 2y ago
    This is great news. I had hacked together some bash and fish scripts to mostly do this but they still had some rough edges. I missed that uv now had this ready for preview
    - kstrauser 2y ago
      I just found that a couple weeks ago. I'm an end user, too. I don't have anything to do with uv development. I stumbled across it in a GitHub issue or something and passed along the info.
IshKebab 2y ago
Uv really fixes Python. It takes it from "oh god I have to fight Python again" to "wow it was actually fast and easy". I think all the other projects (pyenv, poetry, pip, etc.) should voluntarily retire for the good of Python. If everyone moved to Uv right now, Python would be in a far better place. I'm serious. (It's not going to happen though because the Python community has no taste.) The only very minor issue I've had is once or twice the package cache invalidation hasn't worked correctly and `uv pip install` installed an outdated package until I `uv clean`ed. Not a big deal though considering it solves so many Python clusterfucks.
- javchz 2y ago
  Agree. I mostly do front end in my day job, and despite JavaScript being a bit of a mess lang, dealing with npm is way better than juggling anaconda, miniforge, Poetry, pip, venv, etc depending on the project. UV is such a smooth UX that it makes you wonder how something like it wasn’t part of Python from the start.
  - baq 2y ago
    +1 …but we did have to wait for cargo, npm (I include yarn and pnpm here) and maybe golang to blaze the ‘this is how it’s done’ trail. Obvious in hindsight.
    - dontlaugh 2y ago
      Ruby's bundler had already invented the correct model many years ago. It only took time for others to accept that.
      - zelphirkalt 2y ago
        Wait, a bundler? What needs to be bundled when using Ruby? Maybe this is not the same meaning as with JS bundlers. And why does a bundles manage dependencies?
        2y ago
OutOfHere 2y ago
The functionalities of three tooling projects, namely uv, ruff (linter), and pyright (type checker) need to merge and become mandatory for new Python projects. Together they will bring some limited sanity to Python.
- wiseowise 2y ago
  Ruff is already integrated into uv and Astral are working on type checker.
  - maleldil 2y ago
    How is ruff integrated? As far as I understand, it's still a separate tool that you need to install.
- deleted 2y ago
  [deleted]
- __mharrison__ 2y ago
  What benefit does merging provide?
  - OutOfHere 2y ago
    In an ideal world they shouldn't have to, but in the real world, it makes it easier for enterprises to adopt without friction. Adopting three tools is a threefold bigger challenge in enterprises, but thinking about it as a single tool makes it more amenable to enterprise adoption where it's needed the most. The merging I suggest is only logical, more like a bundling.
    - __mharrison__ 2y ago
      Hmmm, I've never seen that and I feel like I work with some pretty locked down companies.
      - 2y ago
ashvardanian 2y ago
I’m enjoying UV a lot as well. If anyone from the Astral team sees this, I’d love to request more functionality or examples around packaging native libraries. At this point, just thinking about updating CIBuildWheel images triggers PTSD—the GitHub CI pipelines become unbearably slow, even for raw CPython bindings that don’t require LibC or PyBind11. It’s especially frustrating because Python is arguably the ultimate glue language for native libraries. If Astral’s tooling could streamline this part of the workflow, I think we’d see a significant boost in the pace of both development & adoption for native and hardware-accelerated tools.
tomrod 2y ago
I love using it. I'm concerned that they go the route of Terraform and put in play pricing and values that differ from what their users support.
mrbonner 2y ago
Ans you can now install Python and set it to the default in your path with the --default flag. Big plus for me to replace pyenv finally.
- thefreeman 2y ago
  finally! this was the thing keeping me from switching every time i looked into it.
kylecordes 2y ago
UV is such a big improvement that it moves Python from my "would use again if I had to, but would really not look forward to it" pile to my "happy to use this as needed" pile. Without disparaging the hard work by many that came before, UV shows just how much previous tools left unsolved.
- crabbone 2y ago
  It doesn't do anything differently beside the speed... Why do people keep praising it so much? It doesn't solve any of the real problems... come on. The problems weren't the tools, the problems are the bad design of the imports and packaging systems which cannot be addressed by an external tool: the language needs to change.
  - ptx 2y ago
    What are the design problems with the imports and packaging systems? How do they need to change?
lmeyerov 2y ago
Are people seeing it work well in GPU/pydata land and creating multiplatform docker images? In the data science world, conda/mamba was needed because of this kind of thing, but a lot of room for improvement. We basically want lockfile, incremental+fast builds, and multi-arch for these tricky deps.
- throwaway314155 2y ago
  Works better than poetry for cuda-versioned pytorch. I don't have overlap with your other domains unfortunately (ML, not data science).
  - lmeyerov 2y ago
    Thanks! I think the comparison for data work is more on conda, not poetry. afaict poetry is more about the "easier" case of pure-python, and not native areas like prebuilt platform-dependent binaries. Maybe poetry got better, but I typically see it more like a nice-to-have for local dev and rounding out the build, but not that recommended install flow for natively-aligned builds. So still curious with folks navigating the 'harder' typical case of the pydata world, getting an improved option here is exciting!
    - throwaway314155 2y ago
      That's fair. I guess when you see people champion poetry (less so lately) you hope it works as well as pip/conda despite the complexities of pytorch in particular. Finding that the community in particular simply doesn't use that library has a shock of sorts - like this package manager is great, but "your type ain't welcome". In any case I believe uv is trying to be _the_ solution and Id be pretty surprised if your libs weren't well supported, or on the roadmap at least.
- maleldil 2y ago
  It works transparently. The lock file is cross-platform by default. When using pytorch, it automatically installs with MPS support on macOS and CUDA on Linux; everything just works. I can't speak for Windows, though.
jgalt212 2y ago
Because pyenv compiles from source, it's optimized for your own platform. In practice, are these performance differences noticeable?
- zahlman 2y ago
  For what it's worth, I didn't notice a difference between my distro-provided Python 3.12 and the one I built from source - and enabling profile-guided optimization made only a slight difference. I haven't tested with the precompiled versions uv uses, so they could be slower for some reason, but I doubt it. On the other hand, my hardware is rather old, so maybe newer machines allow for significant optimizations that the system version wouldn't have. But I still kinda doubt it. If performance is important to you, the ancient advice to profile bottlenecks and implement important parts in C where you can, still applies. Or you can try other implementation like PyPy.
- zanie 2y ago
  Hi! I work on the Python distributions uv uses. Performance is really important to us and we're on the bleeding edge of performant Python builds. Our distributions use profile guided optimization (PGO) as well as post-link optimizations (BOLT). From my understanding, these are not enabled by pyenv by default because they significantly increase build times. It's possible there are some platform-specific build benefits, but I'd be surprised if it was significant. I can set up some benchmarks comparing to pyenv on a couple common platforms – lately I've just been focused on benchmarking changes to CPython itself.
o10449366 2y ago
If uv figures out a way to capture the scientific community by adding support for conda-forge that'll be the killshot for other similar projects, imo. Pixi is too half-baked currently and suffers from some questionable design decisions.
- kyawzazaw 2y ago
  which subfield of scientific community uses that? and for what purpose, if you could summarize
  - tempay 2y ago
    The key thing of conda-forge is that it's language (rust/go/c++/ruby/java/...) and platform (linux/macos/win/ppc64le/aarch64/...) agnostic rather than being python only. If you want you can depend on a C++ and fortran compiler at runtime and (fairly) reliably expect it to work.
- bitvoid 2y ago
  Out of curiosity, which design decisions do you find questionable and what do you feel is half-baked with Pixi? It's been working well for us.
surfingdino 2y ago
So... I am switching a project from pip to uv. I am hoping for things to be "better", but so far it's been a bit of a familiar "why does it not work as described?" journey.
- zahlman 2y ago
  Could you give some detail on things you've found that still don't work as described?
  - surfingdino 2y ago
    I could use more guidance on migration for setups where development and testing is using Docker. I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path.
    - zahlman 2y ago
      > I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path. I'd like to encourage you to blog about it, then.
TheIronYuppie 2y ago
For scripting... HIGHLY recommend putting your dependencies inline. E.g.: #!/usr/bin/env python3 # /// script # requires-python = ">=3.11" # dependencies = [ # "psycopg2-binary", # "pyyaml", # ] # /// Then - uv run -s file.py
- maleldil 2y ago
  How does this interact with your code editor or IDE? When you edit the file, where does the editor look for information about the imported third-party libraries?
  - AlphaSite 2y ago
    Usually the VENV and import lines are enough
    - maleldil 2y ago
      How do you determine where the venv is? AFAIK, uv run in script mode creates the venv in some random temporary directory.
      - JimDabell 2y ago
        I don’t know of a convenient way of doing it, but a clumsy way of doing it is to run this in your script: import os print(os.environ['VIRTUAL_ENV'] + '/bin/python') Then, e.g. in VS Code, you bring up the command palette, run Python: Select Interpreter, and enter the result.
        JimDabell 2y ago
        uv v0.6.10 has just been released with a more convenient way of doing this: uv python find --script foo.py — https://github.com/astral-sh/uv/releases/tag/0.6.10 https://github.com/astral-sh/uv/releases/tag/0.6.10 — https://docs.astral.sh/uv/reference/cli/#uv-python-find--script https://docs.astral.sh/uv/reference/cli/#uv-python-find--scr...
runjake 2y ago
For my use cases, uv is so frictionless it has effectively made Python tolerable for me. I primarily discovered it via Simon Willison's (@simonw) blog posts[1]. I recommend his blog highly. 1. https://simonwillison.net/tags/uv/ https://simonwillison.net/tags/uv/
stuaxo 2y ago
This makes sense for people keen on pyenv. I'm still very keen on virtualenvwrapper, I hope that the fast dependency resolution and install of uv can come there and to poetry.
bigfatfrock 2y ago
I converted along with most of the people in this thread. IMO no really hard problem is ever truly solved but as can be seen in other comments, this group of people really crushed the pain of me and *many* others, so bravo alone on that - you have truly done humanity a service.
xenophonf 2y ago
What does uv offer over bog-standard setuptools, pip, pip-tools, and build? Right now, the only thing I really want is dependency pinning in wheels but not pyproject.yaml, so I can pip install the source and get the latest and greatest, or I can pip install a wheel and get the frozen dependencies I used to build the wheel. Right now, if I want the second case, I have to publish the requirements.txt file and add the wheel to it, which works but is kind of awkward.
- baq 2y ago
  It does everything with less surprises and faster. Just try it.
  - xenophonf 2y ago
    > Just try it. I don't need to be told to RTFM. I was asking for advice. My attention span is my most valuable commodity, and since I'm not really surprised or slowed down by setuptools, etc., it sounds like uv probably isn't worth investigating. Thanks.
    - deleted 2y ago
      [deleted]
    - baq 2y ago
      It probably is. Just try it is the advice.
      - xenophonf 2y ago
        That's unhelpful. To answer my own question—and to actually help other people with similar use cases—I read about uv's build process and dependency locking. It does not appear to be able to lock dependencies for build distributions (wheels). https://docs.astral.sh/uv/concepts/projects/build/ https://docs.astral.sh/uv/concepts/projects/build/ https://docs.astral.sh/uv/pip/compile/ https://docs.astral.sh/uv/pip/compile/ However, it does mention that Python supports multiple build systems, which I didn't know, so this hasn't been a complete waste of my time. Thanks!
77ko 2y ago
uv is excellent! The only think I'm missing is an easy way to update all packages in an env, something like `uv update --all` or `uv update plotly`. Which would fit in with existing uv commands[1] like `uv add plotly`. There is an exisiting `uv lock --upgrade-package requests` but this feels a bit verbose. [1]: https://docs.astral.sh/uv/guides/projects/#creating-a-new-project https://docs.astral.sh/uv/guides/projects/#creating-a-new-pr...
- maxrimue 2y ago
  Are you looking for something like `uv sync --upgrade`? This one should be re-assessing your dependencies (excluding version pinned ones of course) and regenerate the lockfile if I remember correctly. https://docs.astral.sh/uv/reference/cli/#uv-sync--upgrade https://docs.astral.sh/uv/reference/cli/#uv-sync--upgrade
zahlman 2y ago
> Maybe I installed some other things for some reason lost in the sands of time. FWIW, I was able to confirm that the listed primary dependencies account for everything in the `pip freeze` list. (Initially, `userpath` and `pyrsistent` were missing, but they appeared after pinning back the versions of other dependencies. The only project for which I couldn't get a wheel was `python-hglib`, which turned out to be pure Python with a relatively straightforward `setup.py`.)
whimsicalism 2y ago
frankly the only pain point i have working with uv is that it's too new for the LLMs to know about it
- ddejohn 2y ago
  What do LLMs have to do with package and project management?
  - Kwpolska 2y ago
    Some people are too lazy to read docs, so they ask the bullshit generators instead.
    - ddejohn 2y ago
      lol, oy vey
mrlatinos 2y ago
Here we go again.
pzo 2y ago
I want to switch to uv from pyenv but one use case that didn't manage to figure out is if I can have similar setup like pyenv that I install few python version and setup one to be a global default (configured in zsh). I know for bigger projects proper way is to setup virtual environment for all new project but I do many mini (throwaway) python scripts and experiments or testing repos in python and would be really annoying to setup environment for those - so far pyenv worked well for me for such cases without having pretty much dependency conflicts.
- js2 2y ago
  Yes, uv is well suited to that use case by declaring your Python version and/or dependencies right in the script itself: https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d... You can use an alternate shebang line so you can run the script directly: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.12" # dependencies = [ # "requests", # "typer-slim", # ] # /// import requests import typer # ...
  - pzo 2y ago
    Yes but I then still then have to declare all dependencies for all tiny throwaway script, right now I have global python in pyenv and installed tons of plugins and didn't have too much issues with conflicts so was good enough for me
    - biorach 2y ago
      How about just install a python version with uv and install everything into that? Or better, do the above, then create a virtual env, set the virtual env in your.bashrc and install everything into that Better still... use uv script --init See other comments on this post
    - jsmeaton 2y ago
      I used to have the same setup - a global tools venv with some useful dependencies. Uv takes the position that since it’s so fast to install dependencies and create environments, you don’t maintain a global venv. uvx ruff file.py Will setup a venv, install ruff into it, and run over your file. https://docs.astral.sh/uv/guides/tools/ https://docs.astral.sh/uv/guides/tools/ Otherwise you can: uv run —-with package file.py If you don’t want to declare your dependencies. https://docs.astral.sh/uv/guides/scripts/#running-a-script-with-dependencies https://docs.astral.sh/uv/guides/scripts/#running-a-script-w...
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
globular-toast 2y ago
I've stuck with simple tools for all these years: pip, pip-tools, virtualenvwrapper etc. I've tried other stuff like poetry and it's always seemed like hard work. I'm glad I waited for uv. The one thing I wish it supported is having venvs outside of project directories. It's so much nicer to have them all in one place (like ~/.venvs or something) which you can ignore for backups etc. That's the only thing I miss, though.
- sitic 2y ago
  I'm also only missing virtualenvwrapper-like support for central named venvs in uv. I'm too used to type virtualenvwrapper's `workon` and `mkvirtualenv` commands, so I've written some lightweight replacement scripts of virtualenvwrapper when using uv. Supports tab completion and implements only the core functionality of virtualenvwrapper: https://github.com/sitic/uv-virtualenvwrapper https://github.com/sitic/uv-virtualenvwrapper
jillesvangurp 2y ago
I dabble with python occasionally and I'm always fighting with tools and tool combinations that don't really combine well. The last time I settled on using conda to get some isolation of python versions and then pipenv for getting some sane package management with a lock file. Not pretty but it kind of worked. Except I had a hard time convincing vs code and pycharm of the correct environment with that combination (couldn't resolve libraries I installed). I got it working eventually but it wasn't a great experience. It sounds like uv should replace the combination. Of course there is the risk of this being another case of the python community ritually moving the problem every few years without properly solving it. But it sounds like uv is mostly doing the right thing; which is making global package installation the exception rather than the default. Most stuff you install should be for the project only unless you tell it otherwise. Will give this a try next time I need to do some python stuff.
- fnands 2y ago
  Do. I was sceptical at first - exactly because of the points you make: I mostly do ML, so for getting PyTorch and Cuda etc. to play nice conda was basically my go-to. We use poetry at work, but getting it to play nice with PyTorch is always a bit of an art. I tried to get into Pixi, but have been a little annoyed as it seems to have inherited conda's issues when mixing conda and PyPi. uv so far has been relatively smooth sailing, and they even have an entire section on using it with PyTorch: https://docs.astral.sh/uv/guides/integration/pytorch/ https://docs.astral.sh/uv/guides/integration/pytorch/
aequitas 2y ago
I recently switched our Python projects to uv and it love it. It just does everything and is really fast (this just cannot be underestimated in what it means for your workflow). I've tried almost every Python packaging solution under the sun in the past 15 years but they all had their problems. Finally I just stuck with pip/pip-tools and plain venv's but strung together with a complicated Makefile to optimize the entire workflow for iteration speed (rebuilding .txt files when .in requirements changes, rebuilding venv if requirements change, etc). I've been able to reduce it to basically one Make target calling uv to do it all.
mafro 2y ago
I switched to hatch last year for many projects, its been quite pleasant. Has anyone used both hatch and uv, and could comment on that comparison? EDIT: quick google gives me these opinions[1] [1]: https://www.reddit.com/r/Python/comments/1gaz3tm/hatch_or_uv_for_a_new_project/ https://www.reddit.com/r/Python/comments/1gaz3tm/hatch_or_uv...
- mmmrk 2y ago
  We had to drop hatch for now, because it does not work well with uv's lockfiles. Someone opened an issue here: https://github.com/pypa/hatch/issues/1886 https://github.com/pypa/hatch/issues/1886. We use bare uv for now.
avidphantasm 2y ago
I have been using Python for 20 years, and have been an intermediate to advanced user of it for last 5-7 years. I use it mostly for scientific computing (so lots of Numpy, SciPy, etc.), IoT data processing, and also for some microservices that don’t need to be super fast. I publish and maintain a few packages in PyPI and conda (though I almost never use conda myself), including a C++ library with Python bindings generated by SWIG (SWIG wouldn’t be my first choice, but I inherited it). In what I’ve done, I’ve never found things like pipenv, let alone uv, to be necessary. Am I missing something? What would uv get?
- crabbone 2y ago
  If you need to package for Anaconda, uv has nothing to offer you. It's a replacement for a number of PyPA tools, so it's not compatible with Anaconda tools. The selling point of uv is that it does things faster than the tools it aims to replace, but on a conceptual level it doesn't add anything substantially new. The tools it aims to replace were borne of the defects in Python import and packaging systems (something that Anaconda also tried to address, but failed). They are not good tools designed to do things the right way. They are band-aids designed to mitigate some of the more common problems stemming from the bad design choices in the imports and packaging systems. My personal problem with tools like uv is that, just like Web browsers in the early days of the Web tried to win users by tolerating the mistakes made by the Web site authors, it allows to delay the solution of the essential problems that exist in Python infrastructure by offering some pain relief to those who are using the band-aid tools.
randomsolutions 2y ago
My biggest issue is using uv envs in vscode under WSL. Starting up interactive sessions takes forever. Its just too slow, can't figure out what the deal is.
deleted 2y ago
[deleted]
BewareTheYiga 2y ago
I can't say enough good things about UV. It has simplified and accelerated my python and Jupyter projects. I even run it in my pipelines.

351 points by harryvederci 2y ago

oblio 2y ago

How does this compare to Mise: https://mise.jdx.dev/lang/python.html https://mise.jdx.dev/lang/python.html ?

claytonjy 2y ago
mise is higher level. i use it to install uv in projects with other non-python dependencies (helm, terraform, npm), which i also install with mise. Then all the python dependencies are managed with uv. For a non-python project which needs a python-based CLI tool, i’m not sure if i’d use mise or uv (uvx).

xucian 2y ago

has anybody doing complex projects achiever success with uv completely replacing pyenv, and had mostly pros and few or no cons? I'm very comfortable with pyenv, but am extremely open to new stuff

emgeee 2y ago
I've used uv to work on the feast feature store project to great success
NeutralForest 2y ago
Sure, I've basically replaced pyenv, pyenv-virtualenv, poetry; with uv. I can't think about cons personally, though you might need to dig into the docs at times.
ath3nd 2y ago
I worked in a large-ish org where 20+ python projects, their CI/CD pipelines and their docker images were migrated from `pyenv` + `.python-version` + `requirements.txt` to `uv` in basically a single day. If you are comfortable with `pyenv`, the switch to `uv` is basically a walk in the park. The benefit is the speed + the predictable dependencies resolution.
- ttyprintk 2y ago
  Astral ships a Docker image that provides their tox-uv. I saw maybe a 3x speed up setting up environments.
rat87 2y ago
I don't know how complex your project is but I moved my previous work from pyenv to rye(UV and rye have merged, most work is being done on uv, today I'd probably use UV) And am currently trying to move current work to UV. The problems seem to be possibility of unknown breakage for unknown users of the old project not any known technical issue. I'd highly reccomend UV. Its just easier/more flexible. And it downloads third party pre compiled python builds instead of the extra time and complexity to get it compiling locally. Its much nicer especially when maintaing an environment for a team that just works without them having to know about it One downside of UV is that unlike pyenv and rye it doesn't shim python. Pyenv shim did give me some trouble but rye simples shim didn't. The workaround is to run stuff with uv run x.py instead of python x.py
- ttyprintk 2y ago
  `uv tool install` will create shims in .local/bin
  - rat87 2y ago
    Sorry I meant shims for python. I think I mentioned installing tools
- xucian 2y ago
  thanks, running "uv run x.py" is a relevant downside for me, but you definitely brought me closer to actually looking into it. I'm about to sell a project template and it'd look good if I use a newer tool (as long as I'll make sure it's stable and resilient, the latter being a bit hard to estimate, thus my post)
__mharrison__ 2y ago
Teaching a course for a corporate client this week for data scientists. The first day (of five) we covered uv. Minds blown. "Course was worth it just for uv"
- xucian 2y ago
  thanks, this encourages me to explore it more

theogravity 2y ago

Is there a guide for how to use uv if you're a JS dev coming from pnpm? I just want to create a monorepo with python that's purely for making libraries (no server / apps). And is it normal to have a venv for each library package you're building in a uv monorepo?

BiteCode_dev 2y ago
If the libraries are meant to be used together, you can get away with one venv. If they should be decoupled, then one venv per lib is better. There is not much to know: - uv python install <version> if you want a particular version of python to be installed - uv init --vcs none [--python <version>] in each directory to initialize the python project - uv add [--dev] to add libraries to your venv - uv run <cmd> when you want to run a command in the venv That's it, really. Any bonus can be learned later.
- NeutralForest 2y ago
  There's also workspaces (https://docs.astral.sh/uv/concepts/projects/workspaces/ https://docs.astral.sh/uv/concepts/projects/workspaces/) if you have common deps and it's possible to act on a specific member of the workspace as well.
  - BiteCode_dev 2y ago
    That's one of the bonus I was thinking about. It's nice if you have a subset of deps you want to share, or if one dep is actually part of the monorepo, but it does require more to know.
- new_user_final 2y ago
  uv sync if you clone a github repo
  - BiteCode_dev 2y ago
    uv run in the freshly cloned repo will create the venv and install all deps automatically. You can even use --extra and --group with uv run like with uv sync. But in a monorepo, those are rare to use.

unsnap_biceps 2y ago

Uv in script mode has made me love python again.

bnycum 2y ago

I decided to give uv a shot on my new machine over pyenv and I've been enjoying it. Just last week I had to generate out 90 slides from some data last minute. Quickly created a project added in my dependencies (pandas, matplotlib, python-pptx), then crunched out some code. Absolutely zero friction with a much easier to use set of commands in my opinion.

rsyring 2y ago

15 year Python dev who usually adopts tooling slowly. Just do it, uv's absolutely worth it. I also use mise with it, which is a great combination and gives you automatic venv activation among other things. See, among other mise docs related to Python, https://mise.jdx.dev/mise-cookbook/python.html https://mise.jdx.dev/mise-cookbook/python.html See also a Python project template I maintain built on mise + uv: https://github.com/level12/coppy https://github.com/level12/coppy

NeutralForest 2y ago
I used to install Python through mise but now I just use uv tbh.
- rsyring 2y ago
  Similar. But we get other benefits through mise, like tasks and other tool installs (e.g. Terraform). So we still use them together.
  - NeutralForest 2y ago
    That's fair, it's also nice if you have a backend in Python and a frontend in JS since mise also handles node.
    - rsyring 2y ago
      Forgot about that! Yes, another significant benefit of why we use mise. In particular, we use flask-vite and it's so nice to be able to have the right version of Node specified in the same management system as we specify the Python version. This solved a not insignificant amount of angst around FE development for me personally since I spend most of my time in the BE. It's not like it was insurmountable before. But now, with mise, it's in that "just works" category for me.
      - NeutralForest 2y ago

rullopat 2y ago

[flagged]

fwip 2y ago
I think you might have your dates confused. Pyenv was first released about 8 years ago.
alexjplant 2y ago
You're being downvoted (for snark presumably) but you have a point. During my tenures as a Python developer I've had to deal with pip, pipx, venv, pipenv, setuptools, conda, and poetry. I'd not heard of pyenv or uv until this thread (or maybe I've touched pyenv and got it confused with one of the 7 other tools I mentioned) and I'm sure there are other dependency/environment management tools floating around that I missed. Now that I'm back to Go it's `go get` with some mise tasks. It's a serious breath of fresh air. The Python ecosystem probably won't ever catch up to npm when it comes to cranking out shiny new things but it's definitely more bleeding edge than a lot of other languages.
- turtlebits 2y ago
  In the past 10 years, virtualenv and pip have been perfectly fine for me. They still are. I ignored any new tooling. uv is great so far, I did run into a hiccup where moving from pip with a requirements.txt file to uv slowed a CI pipeline way down that I had to revert.
  - __mharrison__ 2y ago
    Odd that it slowed down. I wondered what happened. For me and my clients, uv has been 2-4 orders of magnitude faster.
- rat87 2y ago
  The reason there have been so many is because the standard included tools (pip, venv) are not great. And others could still use improvements. Venv and setup tools aren't really package managers. Pipx is only meant for installing Dev tools per user (in isolated Venvs). pyenv does something a bit different from those tools you listed(maybe it'd part of cones I haven't tried it). Its not a dependency manager its a python version manager like nvm (node version manager). It helps you manage downloading and compiling python from source and it let's you specify python version in a .python-version file and provides a shim to find the right python for a project(compiling it if its not already available). I tried pipenv and despite being hyped for it, it had a lot of issues. Then I tried poetry which seemed much better but was still sort of slow and got stuck updating lock files sometimes. I haven't even tried pdm. Or various conda package managers since its mainly used by scientists with lots of binary dependency needs. Then ~~uv~~ rye came along and seemed to fix things. It replaced pip+pip tools/pipenv/poetry. Also replaced pipx(install python tools in isolated venvs then add it to users ./local/bin). Also replaced pyenv but instead of compiling python which takes a while and can be troublesome it downloads portable builds https://astral.sh/blog/python-build-standalone https://astral.sh/blog/python-build-standalone (which do have some downsides/compatibility issues but are usually better then compiling python). It was also written in rust so avoided circular venv issues that sometimes come with installing python packages since it had a self contained binary(plus some shims). Then UV came along, the projects merged and most development is happening in uv. Despite the rye-> switch most things are pretty similar and I feel a lot of excitement towards it. The one big difference is there's no shims to automatically call the right python for a project from UV. Instead you need to run uv run script.py Astral the guys behind UV took over the independent python builds and have also built the most popular python formater/linter these days - ruff (also written in rust, also fast they're also looking into adding a better type checker for python type hints). I'd reccomend trying it for your next project I think it could become the defacto packaging/version tool for python

quickslowdown 2y ago

I highly, highly recommend uv. It solves & installs dependencies incredibly fast, and the CLI is very intuitive once you've memorized a couple commands. It handles monorepos well with the "workspaces" concept, it can replace pipx with "uv tool install," handle building & publishing, and the docker image is great, you just add a FROM line to the top and copy the bin from /uv. I've used 'em all, pip + virtualenv, conda (and all its variants), Poetry, PDM (my personal favorite before switching to uv). Uv handles everything I need in a way that makes it so I don't have to reach for other tools, or really even think about what uv is doing. It just works, and it works great. I even use it for small scripts. You can run "uv init --script <script_name.py>" and then "uv add package1 package2 package3 --script <script_name.py>". This adds an oddly formatted comment to the top of the script and instructs uv which packages to install when you run it. The first time you run "uv run <script_name.py>," uv installs everything you need and executes the script. Subsequent executions use the cached dependencies so it starts immediately. If you're going to ask me to pitch you on why it's better than your current preference, I'm not going to do that. Uv is very easy to install & test, I really recommend giving it a try on your next script or pet project!

midhun1234 2y ago
Can confirm this is all true. I used to be the "why should I switch" guy. The productivity improvement from not context switching while pip installs a requirements file is completely worth it.
baby_souffle 2y ago
I didn't know that UV would now edit the script for you. That is just icing on the cake! For the curious, the format is codified here: https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/
scribu 2y ago
The install speed alone makes it worthwhile for me. It went from minutes to seconds.
- BoorishBears 2y ago

eikenberry 2y ago

Maybe this one will finally be adopted as the official package manager for Python? Only 20 years late, but it would be a nice development.

0cf8612b2e1e 2y ago
Pfft. Pull the other one. The PSF hates the idea of dealing with something so icky. I have been pretty pleased with uv, but I am continually worried about the funding model. What happens when the VC starts demanding a return?
- __MatrixMan__ 2y ago
  We fork it. Whatever carrot the VC's dangle can be chased by the handful who care, and the rest of us can continue using the important part.
  - Kwpolska 2y ago
    Ah, so that's why it's written in Rust. Less people who care about Python packaging are capable of forking it.
    - __MatrixMan__ 2y ago
      I guess this is a joke but honestly I think that Python -> Rust is a pretty strong one. I'd bet that the sort of person who is maintaining packaging for a bunch of Python users would like an opportunity to learn Rust on the job. I would.
      - eikenberry 2y ago
        IMO this is unlikely. Rust and Python have very little in common.
wirHga 2y ago
Please not. Python core is suffering from corporate capture and ruins everything it touches. The PSF would probably dig up some old posts from the uv authors, defame them, take the code and make it worse.

vslira 2y ago

I'm using exclusively uv for personal projects - and small prototypes at work - and I can't recommend it enough. Uv makes python go from "batteries included" to "attached to a nuclear reactor"

scratchyone 2y ago
i’ve started slipping uv into production work projects along with an auto generated requirements.txt for anyone who doesn’t wanna use uv. hoping i can drive adoption on my team while still leaving an alternative for people who don’t wanna use it
- globular-toast 2y ago
  You mean `uv pip compile pyproject.toml > requirements.txt`?

kubav027 2y ago

I am pretty happy with poetry for near future. I prefer using python interpreters installed by linux package manager. In cloud I use python docker. Poetry recently added option to install python too if I changed my mind. I have already setup CI/CD pipelines for programs and python libraries. Using uv would probably save some time on dependency updates but it would require changing my workflow and CI/CD. I do not think it is worth the time right now. But if you use older environments without proper lock file I would recommend switching immediately. Poetry v2 supports pyproject.toml close to format used by uv so I can switch anytime when it would look more appealing. Another thing to consider in long term is how astral tooling would change when they will need to make money.

js2 2y ago
> I prefer using python interpreters installed by linux package manager. uv will defer to any python it finds in PATH as long as it satisfies your version requirements (if any): https://docs.astral.sh/uv/concepts/python-versions/ https://docs.astral.sh/uv/concepts/python-versions/ It also respects any virtual environment you've already created, so you can also do something like this: /usr/bin/python3 -m venv .venv .venv/bin/pip install uv .venv/bin/uv install -r requirements.txt # or .venv/bin/uv run script ... It's a very flexible and well thought out tool and somehow it manages to do what I think it ought to do. I rarely need to go to its documentation. > Using uv would probably save some time on dependency updates but it would require changing my workflow and CI/CD. I found it very straightforward to switch to uv. It accommodates most existing workflows.
irjustin 2y ago
I'm pretty much with you and still trying to figure out why I want to switch away from pyenv+poetry. I get that uv does both, but I'm very happy with pyenv+poetry combo. Old baggage, but I came from the rvm world which attempted to do exactly what uv does, but rvm was an absolute mess in 2013. rbenv+bundler solved so many problems for me and the experience was so bad that when I saw uv my gut reaction was to say "never again". But this thread has so many praises for it so one day maybe i'll give it a try.
- 2y ago

BiteCode_dev 2y ago

Note that despite the title, the author is not switching from pyenv to uv, but from pip, pyenv, pipx, pip-tools, and pipdeptree to uv, because uv does much more than pyenv alone. It replaces a whole stack, and does each feature better, faster, with fewer modes of failure.

moltar 2y ago

I wasn’t able to figure how to make a uv installed python version a global when “python” is called, at least in the current shell, as I need it in CI.

kstrauser 2y ago
That feature's in preview now. You can run it like: uv python install --preview --default 3.13 and then you get Python 3.13 whenever you run `python` outside of an environment that declares something else.
- moltar 2y ago
  Thank you!! Will try it tomorrow.
  - kstrauser 2y ago
    You bet. I was so happy to find that!
- leejoramo 2y ago
  This is great news. I had hacked together some bash and fish scripts to mostly do this but they still had some rough edges. I missed that uv now had this ready for preview
  - kstrauser 2y ago
    I just found that a couple weeks ago. I'm an end user, too. I don't have anything to do with uv development. I stumbled across it in a GitHub issue or something and passed along the info.

IshKebab 2y ago

Uv really fixes Python. It takes it from "oh god I have to fight Python again" to "wow it was actually fast and easy". I think all the other projects (pyenv, poetry, pip, etc.) should voluntarily retire for the good of Python. If everyone moved to Uv right now, Python would be in a far better place. I'm serious. (It's not going to happen though because the Python community has no taste.) The only very minor issue I've had is once or twice the package cache invalidation hasn't worked correctly and `uv pip install` installed an outdated package until I `uv clean`ed. Not a big deal though considering it solves so many Python clusterfucks.

javchz 2y ago
Agree. I mostly do front end in my day job, and despite JavaScript being a bit of a mess lang, dealing with npm is way better than juggling anaconda, miniforge, Poetry, pip, venv, etc depending on the project. UV is such a smooth UX that it makes you wonder how something like it wasn’t part of Python from the start.
- baq 2y ago
  +1 …but we did have to wait for cargo, npm (I include yarn and pnpm here) and maybe golang to blaze the ‘this is how it’s done’ trail. Obvious in hindsight.
  - dontlaugh 2y ago
    Ruby's bundler had already invented the correct model many years ago. It only took time for others to accept that.
    - zelphirkalt 2y ago
      Wait, a bundler? What needs to be bundled when using Ruby? Maybe this is not the same meaning as with JS bundlers. And why does a bundles manage dependencies?
      - 2y ago

OutOfHere 2y ago

The functionalities of three tooling projects, namely uv, ruff (linter), and pyright (type checker) need to merge and become mandatory for new Python projects. Together they will bring some limited sanity to Python.

wiseowise 2y ago
Ruff is already integrated into uv and Astral are working on type checker.
- maleldil 2y ago
  How is ruff integrated? As far as I understand, it's still a separate tool that you need to install.
deleted 2y ago
[deleted]
__mharrison__ 2y ago
What benefit does merging provide?
- OutOfHere 2y ago
  In an ideal world they shouldn't have to, but in the real world, it makes it easier for enterprises to adopt without friction. Adopting three tools is a threefold bigger challenge in enterprises, but thinking about it as a single tool makes it more amenable to enterprise adoption where it's needed the most. The merging I suggest is only logical, more like a bundling.
  - __mharrison__ 2y ago
    Hmmm, I've never seen that and I feel like I work with some pretty locked down companies.
    - 2y ago

ashvardanian 2y ago

I’m enjoying UV a lot as well. If anyone from the Astral team sees this, I’d love to request more functionality or examples around packaging native libraries. At this point, just thinking about updating CIBuildWheel images triggers PTSD—the GitHub CI pipelines become unbearably slow, even for raw CPython bindings that don’t require LibC or PyBind11. It’s especially frustrating because Python is arguably the ultimate glue language for native libraries. If Astral’s tooling could streamline this part of the workflow, I think we’d see a significant boost in the pace of both development & adoption for native and hardware-accelerated tools.

tomrod 2y ago

I love using it. I'm concerned that they go the route of Terraform and put in play pricing and values that differ from what their users support.

mrbonner 2y ago

Ans you can now install Python and set it to the default in your path with the --default flag. Big plus for me to replace pyenv finally.

thefreeman 2y ago
finally! this was the thing keeping me from switching every time i looked into it.

kylecordes 2y ago

UV is such a big improvement that it moves Python from my "would use again if I had to, but would really not look forward to it" pile to my "happy to use this as needed" pile. Without disparaging the hard work by many that came before, UV shows just how much previous tools left unsolved.

crabbone 2y ago
It doesn't do anything differently beside the speed... Why do people keep praising it so much? It doesn't solve any of the real problems... come on. The problems weren't the tools, the problems are the bad design of the imports and packaging systems which cannot be addressed by an external tool: the language needs to change.
- ptx 2y ago
  What are the design problems with the imports and packaging systems? How do they need to change?

lmeyerov 2y ago

Are people seeing it work well in GPU/pydata land and creating multiplatform docker images? In the data science world, conda/mamba was needed because of this kind of thing, but a lot of room for improvement. We basically want lockfile, incremental+fast builds, and multi-arch for these tricky deps.

throwaway314155 2y ago
Works better than poetry for cuda-versioned pytorch. I don't have overlap with your other domains unfortunately (ML, not data science).
- lmeyerov 2y ago
  Thanks! I think the comparison for data work is more on conda, not poetry. afaict poetry is more about the "easier" case of pure-python, and not native areas like prebuilt platform-dependent binaries. Maybe poetry got better, but I typically see it more like a nice-to-have for local dev and rounding out the build, but not that recommended install flow for natively-aligned builds. So still curious with folks navigating the 'harder' typical case of the pydata world, getting an improved option here is exciting!
  - throwaway314155 2y ago
    That's fair. I guess when you see people champion poetry (less so lately) you hope it works as well as pip/conda despite the complexities of pytorch in particular. Finding that the community in particular simply doesn't use that library has a shock of sorts - like this package manager is great, but "your type ain't welcome". In any case I believe uv is trying to be _the_ solution and Id be pretty surprised if your libs weren't well supported, or on the roadmap at least.
maleldil 2y ago
It works transparently. The lock file is cross-platform by default. When using pytorch, it automatically installs with MPS support on macOS and CUDA on Linux; everything just works. I can't speak for Windows, though.

jgalt212 2y ago

Because pyenv compiles from source, it's optimized for your own platform. In practice, are these performance differences noticeable?

zahlman 2y ago
For what it's worth, I didn't notice a difference between my distro-provided Python 3.12 and the one I built from source - and enabling profile-guided optimization made only a slight difference. I haven't tested with the precompiled versions uv uses, so they could be slower for some reason, but I doubt it. On the other hand, my hardware is rather old, so maybe newer machines allow for significant optimizations that the system version wouldn't have. But I still kinda doubt it. If performance is important to you, the ancient advice to profile bottlenecks and implement important parts in C where you can, still applies. Or you can try other implementation like PyPy.
zanie 2y ago
Hi! I work on the Python distributions uv uses. Performance is really important to us and we're on the bleeding edge of performant Python builds. Our distributions use profile guided optimization (PGO) as well as post-link optimizations (BOLT). From my understanding, these are not enabled by pyenv by default because they significantly increase build times. It's possible there are some platform-specific build benefits, but I'd be surprised if it was significant. I can set up some benchmarks comparing to pyenv on a couple common platforms – lately I've just been focused on benchmarking changes to CPython itself.

o10449366 2y ago

If uv figures out a way to capture the scientific community by adding support for conda-forge that'll be the killshot for other similar projects, imo. Pixi is too half-baked currently and suffers from some questionable design decisions.

kyawzazaw 2y ago
which subfield of scientific community uses that? and for what purpose, if you could summarize
- tempay 2y ago
  The key thing of conda-forge is that it's language (rust/go/c++/ruby/java/...) and platform (linux/macos/win/ppc64le/aarch64/...) agnostic rather than being python only. If you want you can depend on a C++ and fortran compiler at runtime and (fairly) reliably expect it to work.
bitvoid 2y ago
Out of curiosity, which design decisions do you find questionable and what do you feel is half-baked with Pixi? It's been working well for us.

surfingdino 2y ago

So... I am switching a project from pip to uv. I am hoping for things to be "better", but so far it's been a bit of a familiar "why does it not work as described?" journey.

zahlman 2y ago
Could you give some detail on things you've found that still don't work as described?
- surfingdino 2y ago
  I could use more guidance on migration for setups where development and testing is using Docker. I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path.
  - zahlman 2y ago
    > I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path. I'd like to encourage you to blog about it, then.

TheIronYuppie 2y ago

For scripting... HIGHLY recommend putting your dependencies inline. E.g.: #!/usr/bin/env python3 # /// script # requires-python = ">=3.11" # dependencies = [ # "psycopg2-binary", # "pyyaml", # ] # /// Then - uv run -s file.py

maleldil 2y ago
How does this interact with your code editor or IDE? When you edit the file, where does the editor look for information about the imported third-party libraries?
- AlphaSite 2y ago
  Usually the VENV and import lines are enough
  - maleldil 2y ago
    How do you determine where the venv is? AFAIK, uv run in script mode creates the venv in some random temporary directory.
    - JimDabell 2y ago
      I don’t know of a convenient way of doing it, but a clumsy way of doing it is to run this in your script: import os print(os.environ['VIRTUAL_ENV'] + '/bin/python') Then, e.g. in VS Code, you bring up the command palette, run Python: Select Interpreter, and enter the result.
      - JimDabell 2y ago
        uv v0.6.10 has just been released with a more convenient way of doing this: uv python find --script foo.py — https://github.com/astral-sh/uv/releases/tag/0.6.10 https://github.com/astral-sh/uv/releases/tag/0.6.10 — https://docs.astral.sh/uv/reference/cli/#uv-python-find--script https://docs.astral.sh/uv/reference/cli/#uv-python-find--scr...

runjake 2y ago

For my use cases, uv is so frictionless it has effectively made Python tolerable for me. I primarily discovered it via Simon Willison's (@simonw) blog posts[1]. I recommend his blog highly. 1. https://simonwillison.net/tags/uv/ https://simonwillison.net/tags/uv/

stuaxo 2y ago

This makes sense for people keen on pyenv. I'm still very keen on virtualenvwrapper, I hope that the fast dependency resolution and install of uv can come there and to poetry.

bigfatfrock 2y ago

I converted along with most of the people in this thread. IMO no really hard problem is ever truly solved but as can be seen in other comments, this group of people really crushed the pain of me and *many* others, so bravo alone on that - you have truly done humanity a service.

xenophonf 2y ago

What does uv offer over bog-standard setuptools, pip, pip-tools, and build? Right now, the only thing I really want is dependency pinning in wheels but not pyproject.yaml, so I can pip install the source and get the latest and greatest, or I can pip install a wheel and get the frozen dependencies I used to build the wheel. Right now, if I want the second case, I have to publish the requirements.txt file and add the wheel to it, which works but is kind of awkward.

baq 2y ago
It does everything with less surprises and faster. Just try it.
- xenophonf 2y ago
  > Just try it. I don't need to be told to RTFM. I was asking for advice. My attention span is my most valuable commodity, and since I'm not really surprised or slowed down by setuptools, etc., it sounds like uv probably isn't worth investigating. Thanks.
  - deleted 2y ago
    [deleted]
  - baq 2y ago
    It probably is. Just try it is the advice.
    - xenophonf 2y ago
      That's unhelpful. To answer my own question—and to actually help other people with similar use cases—I read about uv's build process and dependency locking. It does not appear to be able to lock dependencies for build distributions (wheels). https://docs.astral.sh/uv/concepts/projects/build/ https://docs.astral.sh/uv/concepts/projects/build/ https://docs.astral.sh/uv/pip/compile/ https://docs.astral.sh/uv/pip/compile/ However, it does mention that Python supports multiple build systems, which I didn't know, so this hasn't been a complete waste of my time. Thanks!

77ko 2y ago

uv is excellent! The only think I'm missing is an easy way to update all packages in an env, something like `uv update --all` or `uv update plotly`. Which would fit in with existing uv commands[1] like `uv add plotly`. There is an exisiting `uv lock --upgrade-package requests` but this feels a bit verbose. [1]: https://docs.astral.sh/uv/guides/projects/#creating-a-new-project https://docs.astral.sh/uv/guides/projects/#creating-a-new-pr...

maxrimue 2y ago
Are you looking for something like `uv sync --upgrade`? This one should be re-assessing your dependencies (excluding version pinned ones of course) and regenerate the lockfile if I remember correctly. https://docs.astral.sh/uv/reference/cli/#uv-sync--upgrade https://docs.astral.sh/uv/reference/cli/#uv-sync--upgrade

zahlman 2y ago

> Maybe I installed some other things for some reason lost in the sands of time. FWIW, I was able to confirm that the listed primary dependencies account for everything in the `pip freeze` list. (Initially, `userpath` and `pyrsistent` were missing, but they appeared after pinning back the versions of other dependencies. The only project for which I couldn't get a wheel was `python-hglib`, which turned out to be pure Python with a relatively straightforward `setup.py`.)

whimsicalism 2y ago

frankly the only pain point i have working with uv is that it's too new for the LLMs to know about it

ddejohn 2y ago
What do LLMs have to do with package and project management?
- Kwpolska 2y ago
  Some people are too lazy to read docs, so they ask the bullshit generators instead.
  - ddejohn 2y ago
    lol, oy vey

mrlatinos 2y ago

Here we go again.

pzo 2y ago

I want to switch to uv from pyenv but one use case that didn't manage to figure out is if I can have similar setup like pyenv that I install few python version and setup one to be a global default (configured in zsh). I know for bigger projects proper way is to setup virtual environment for all new project but I do many mini (throwaway) python scripts and experiments or testing repos in python and would be really annoying to setup environment for those - so far pyenv worked well for me for such cases without having pretty much dependency conflicts.

js2 2y ago
Yes, uv is well suited to that use case by declaring your Python version and/or dependencies right in the script itself: https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies https://docs.astral.sh/uv/guides/scripts/#declaring-script-d... You can use an alternate shebang line so you can run the script directly: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.12" # dependencies = [ # "requests", # "typer-slim", # ] # /// import requests import typer # ...
- pzo 2y ago
  Yes but I then still then have to declare all dependencies for all tiny throwaway script, right now I have global python in pyenv and installed tons of plugins and didn't have too much issues with conflicts so was good enough for me
  - biorach 2y ago
    How about just install a python version with uv and install everything into that? Or better, do the above, then create a virtual env, set the virtual env in your.bashrc and install everything into that Better still... use uv script --init See other comments on this post
  - jsmeaton 2y ago
    I used to have the same setup - a global tools venv with some useful dependencies. Uv takes the position that since it’s so fast to install dependencies and create environments, you don’t maintain a global venv. uvx ruff file.py Will setup a venv, install ruff into it, and run over your file. https://docs.astral.sh/uv/guides/tools/ https://docs.astral.sh/uv/guides/tools/ Otherwise you can: uv run —-with package file.py If you don’t want to declare your dependencies. https://docs.astral.sh/uv/guides/scripts/#running-a-script-with-dependencies https://docs.astral.sh/uv/guides/scripts/#running-a-script-w...

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

globular-toast 2y ago

I've stuck with simple tools for all these years: pip, pip-tools, virtualenvwrapper etc. I've tried other stuff like poetry and it's always seemed like hard work. I'm glad I waited for uv. The one thing I wish it supported is having venvs outside of project directories. It's so much nicer to have them all in one place (like ~/.venvs or something) which you can ignore for backups etc. That's the only thing I miss, though.

sitic 2y ago
I'm also only missing virtualenvwrapper-like support for central named venvs in uv. I'm too used to type virtualenvwrapper's `workon` and `mkvirtualenv` commands, so I've written some lightweight replacement scripts of virtualenvwrapper when using uv. Supports tab completion and implements only the core functionality of virtualenvwrapper: https://github.com/sitic/uv-virtualenvwrapper https://github.com/sitic/uv-virtualenvwrapper

jillesvangurp 2y ago

I dabble with python occasionally and I'm always fighting with tools and tool combinations that don't really combine well. The last time I settled on using conda to get some isolation of python versions and then pipenv for getting some sane package management with a lock file. Not pretty but it kind of worked. Except I had a hard time convincing vs code and pycharm of the correct environment with that combination (couldn't resolve libraries I installed). I got it working eventually but it wasn't a great experience. It sounds like uv should replace the combination. Of course there is the risk of this being another case of the python community ritually moving the problem every few years without properly solving it. But it sounds like uv is mostly doing the right thing; which is making global package installation the exception rather than the default. Most stuff you install should be for the project only unless you tell it otherwise. Will give this a try next time I need to do some python stuff.

fnands 2y ago
Do. I was sceptical at first - exactly because of the points you make: I mostly do ML, so for getting PyTorch and Cuda etc. to play nice conda was basically my go-to. We use poetry at work, but getting it to play nice with PyTorch is always a bit of an art. I tried to get into Pixi, but have been a little annoyed as it seems to have inherited conda's issues when mixing conda and PyPi. uv so far has been relatively smooth sailing, and they even have an entire section on using it with PyTorch: https://docs.astral.sh/uv/guides/integration/pytorch/ https://docs.astral.sh/uv/guides/integration/pytorch/

aequitas 2y ago

I recently switched our Python projects to uv and it love it. It just does everything and is really fast (this just cannot be underestimated in what it means for your workflow). I've tried almost every Python packaging solution under the sun in the past 15 years but they all had their problems. Finally I just stuck with pip/pip-tools and plain venv's but strung together with a complicated Makefile to optimize the entire workflow for iteration speed (rebuilding .txt files when .in requirements changes, rebuilding venv if requirements change, etc). I've been able to reduce it to basically one Make target calling uv to do it all.

mafro 2y ago

I switched to hatch last year for many projects, its been quite pleasant. Has anyone used both hatch and uv, and could comment on that comparison? EDIT: quick google gives me these opinions[1] [1]: https://www.reddit.com/r/Python/comments/1gaz3tm/hatch_or_uv_for_a_new_project/ https://www.reddit.com/r/Python/comments/1gaz3tm/hatch_or_uv...

mmmrk 2y ago
We had to drop hatch for now, because it does not work well with uv's lockfiles. Someone opened an issue here: https://github.com/pypa/hatch/issues/1886 https://github.com/pypa/hatch/issues/1886. We use bare uv for now.

avidphantasm 2y ago

I have been using Python for 20 years, and have been an intermediate to advanced user of it for last 5-7 years. I use it mostly for scientific computing (so lots of Numpy, SciPy, etc.), IoT data processing, and also for some microservices that don’t need to be super fast. I publish and maintain a few packages in PyPI and conda (though I almost never use conda myself), including a C++ library with Python bindings generated by SWIG (SWIG wouldn’t be my first choice, but I inherited it). In what I’ve done, I’ve never found things like pipenv, let alone uv, to be necessary. Am I missing something? What would uv get?

crabbone 2y ago
If you need to package for Anaconda, uv has nothing to offer you. It's a replacement for a number of PyPA tools, so it's not compatible with Anaconda tools. The selling point of uv is that it does things faster than the tools it aims to replace, but on a conceptual level it doesn't add anything substantially new. The tools it aims to replace were borne of the defects in Python import and packaging systems (something that Anaconda also tried to address, but failed). They are not good tools designed to do things the right way. They are band-aids designed to mitigate some of the more common problems stemming from the bad design choices in the imports and packaging systems. My personal problem with tools like uv is that, just like Web browsers in the early days of the Web tried to win users by tolerating the mistakes made by the Web site authors, it allows to delay the solution of the essential problems that exist in Python infrastructure by offering some pain relief to those who are using the band-aid tools.

randomsolutions 2y ago

My biggest issue is using uv envs in vscode under WSL. Starting up interactive sessions takes forever. Its just too slow, can't figure out what the deal is.

deleted 2y ago

[deleted]

BewareTheYiga 2y ago

I can't say enough good things about UV. It has simplified and accelerated my python and Jupyter projects. I even run it in my pipelines.