Live data from Hacker News

Switching from Pyenv to Uv

bluesock.org

161–170 of 239 posts

Re: Switching from Pyenv to Uv

#161
post #118
post #108

Earlier quoted context omitted.

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-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 typ…

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

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/

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-w...

Re: Switching from Pyenv to Uv

#162

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…

> It solves & installs dependencies incredibly fast

If you are lucky, and you don't have to build them, because the exceptionally gifted person who packaged them didn't know how to distribute them and the bright minds running PyPI.org allowed that garbage to be uploaded and made it so pip would install that garbage by default.

> can replace pipx with "uv tool install,"

That's a stupid idea. Nobody needed pipx in the first place... The band-aid that was applied some years ago is now cast in stone...

The whole idea of Python tools trying to replace virtual environment, but doing it slightly better is moronic. The virtual environments is the band-aid. It needs to go. The Python developers need to be pressured into removing this garbage, and instead working on having program manifests or something similar. Python has virtual environments due to incompetence of its authors and unwillingness to make things right, once that incompetence was discovered.

----

NB. As it stands today, if you want to make your project work well, you shouldn't use any tools that install packages by solving dependencies and downloading them from PyPI. It's not the function of the tool doing that, it's the bad design of the index.

The reasonable thing to do is to install the packages (for applications) you need during development, figure out what you actually need, and then store the part you need for your package to work locally. Only repeat this process when you feel the need to upgrade.

If you need packages for libraries, then you need a way to install various permutations within allowed versions: no tool for package installation today knows how to do it. So, you might as well not use any anyways.

But, the ironic part is that nobody in Python community does it right. And that's why there are tons of incompatibilities, and the numbers increase dramatically when projects age even slightly.

Re: Switching from Pyenv to Uv

#163
post #23

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"

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

You mean `uv pip compile pyproject.toml > requirements.txt`?

Re: Switching from Pyenv to Uv

#164

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…

> It solves & installs dependencies incredibly fast If you are lucky, and you don't have to build them, because the exceptionally gifted person who packaged them didn't know how to distribute them and the bright minds running PyPI.org allowed that garbage to be uploaded and made it so pip would install that garbage by default. > can replace pipx with "uv tool install," That's a stupid idea. Nobody needed pipx in the…

[flagged]

Re: Switching from Pyenv to Uv

#165

Earlier quoted context omitted.

I generally agree but one thing I find very frustrating (i.e. have not figured out yet) is how deal with extras well, particularly with pytorch. Some of my machines have GPU, some don't and things like "uv add" end up uninstalling everything and installing the opposite forcing a resync with the appropriate --extra tag. The examples in the docs do things like CPU on windows and GPU on Linux but all my boxes are linux.…

i use uv+torch+cuda on linux just fine,never used the extra flag, i wonder what's the problem here?

Getting something that works out of the box on just your computer is normally fine. Getting something that works out of the box on many different computers with many different OS and hardware configurations is much much harder.

Re: Switching from Pyenv to Uv

#166

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'v…

Uv doesn't fix anything. The fixing that Python needs is the removal of the concept of virtual environments and fixing the import and packaging systems instead.

The only thing it does, it makes bad things happen faster. Who cares...

Re: Switching from Pyenv to Uv

#167

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'v…

True. I had to give up on mypy and move to pyright because mypy uses pip to install missing types and they refuse to support uv. In the CI pipeline where I use UV, I don't have a pip installed so mypy complains about missing pip. Of course I can do it by myself by adding typing pkgs to requirement.txt file then what's the point of devtools! And I don't want requirements.txt when I already got pyproject.toml. Once you…

Mypy doesn't install anything by default, you're probably setting the `--install-types` flag somehow.

Re: Switching from Pyenv to Uv

#168

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 gene…

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.

Re: Switching from Pyenv to Uv

#169

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.

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.

Re: Switching from Pyenv to Uv

#170

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 thin…

Yeah, using the package manager is the logical choice and usually the most likely one to work.

IIRC, uv downloads dynamically linked builds of Python, which may or may not work depending on your distribution and whether linked libraries are locally available or not. Not sure if things have changed in recent times.

Post reply on HN