Live data from Hacker News

Uv's killer feature is making ad-hoc environments easy

valatka.dev

171–180 of 428 posts

Re: Uv's killer feature is making ad-hoc environments easy

#171
post #157

Earlier quoted context omitted.

Couple of things. - pip doesn't handle your Python executable, just your Python dependencies. So if you want/need to swap between Python versions (3.11 to 3.12 for example), it doesn't give you anything. Generally people use an additional tool such as pyenv to manage this. Tools like uv and Poetry do this as well as handling dependencies - pip doesn't resolve dependencies of dependencies. pip will only respect versio…

Yes, generally people already use an additional tool for managing their Python executables, like their operating system's package manager: $> sudo apt-get install python3.10 python3.11 python3.12 And then it's simple to create and use version-specific virtual environments: $> python3.11 -m venv .venv3.11 $> source .venv3.11/bin/activate $> pip install -r requirements.txt You are incorrect about needing to use an addi…

(I've just learned about uv, and it looks like I have to pick it up since it performs very well.)

I just use pipx. Install guides suggest it, and it is only one character different from pip.

With Nix, it is very easy to run multiple versions of same software. The path will always be the same, meaning you can depend on versions. This is nice glue for pipx.

My pet peeve with Python and Vim is all these different package managers. Every once in a while a new one is out and I don't know if it will gain momentum. For example, I use Plug now in Vim but notice documentation often refers to different alternatives these days. With Python it is pip, poetry, pip search no longer working, pipx, and now uv (I probably forgot some things).

Re: Uv's killer feature is making ad-hoc environments easy

#172
post #12

I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you…

What is the deal with uv's ownership policy? I heard it might be VC backed. To my mind, that means killing pip and finding some kind of subscription revenue source which makes me uneasy. The only way to justify VC money is a plot to take over the ecosystem and then profit off of a dominant position. (e.g. the Uber model) I've heard a little bit about UV's technical achievements, which are impressive, but technical pr…

It’s dual MIT and Apache licensed. Worst case, if there’s a rug pull, fork it.

Re: Uv's killer feature is making ad-hoc environments easy

#173
post #167
post #104

Earlier quoted context omitted.

I don't feel strongly, but as a uv author, I found "local dependencies" misleading. It's more like "uv's killer feature is making ad-hoc environments easy". When we talk about local dependencies in the Python packaging ecosystem, it's usually adding some package on your file system to your environment. The existing title made me think this would be about the `[tool.uv.sources]` feature. Really, it's about how we crea…

Happy to take correction from an author! I've switched the wording above.

Thanks!

Re: Uv's killer feature is making ad-hoc environments easy

#174
post #12

I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you…

I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?

Cool story bro.

I've used pip, pyenv, poetry, all are broken in one way or another, and have blind spots they don't serve.

If your needs are simple (not mixing Python versions, simple dependencies, not packaging, etc) you can do it with pip, or even with tarballs and make install.

Re: Uv's killer feature is making ad-hoc environments easy

#175
post #28
post #19

Earlier quoted context omitted.

Pip only has requirements.txt and doesn't have lockfiles, so you can't guarantee that the bugs you're seeing on your system are the same as the bugs on your production system.

I’ve always worked around that by having a requirements.base.txt and a requirements.txt for the locked versions. Obviously pip doesn’t do that for you but it’s not hard to manage yourself. Having said that, I’m going to give uv a shot because I hear so many good things about it.

This works until you need to upgrade something, pip might upgrade to a broken set of dependencies. Or if you run on a different OS and the dependencies are different there (because of env markers), your requirements file won't capture that. There are a lot of gotchas that pip can't fix.

Re: Uv's killer feature is making ad-hoc environments easy

#176
post #28

Earlier quoted context omitted.

I’ve always worked around that by having a requirements.base.txt and a requirements.txt for the locked versions. Obviously pip doesn’t do that for you but it’s not hard to manage yourself. Having said that, I’m going to give uv a shot because I hear so many good things about it.

I’m grouchy because I finally got religion on poetry a few years ago, but the hype on uv is good enough that I’ll have to give it a shot.

With the new major release of Poetry that just came out I also feel like it might be a good time to switch to Uv rather than adapt to this new version: https://python-poetry.org/blog/announcing-poetry-2.0.0/

Re: Uv's killer feature is making ad-hoc environments easy

#177
post #115
post #100

Earlier quoted context omitted.

Just because you don't understand it, it's ok to call it an "anti-pattern"? Reproducibility is important in many contexts, especially CI, which is why in Node.js world you literally do "npm ci" that installs exact versions for you. If you haven't found it necessary, it's because you haven't run into situations where not doing this causes trouble, like a lot of trouble.

Just because someone has a different perspective than you doesn't mean they don't "understand". Lockfiles are an anti-pattern if you're developing a library rather than an application, because you can't push your transitive requirements onto the users of your library.

You literally phrased it as "I have no idea why". You can't be upset if someone feels you don't understand why.

Re: Uv's killer feature is making ad-hoc environments easy

#178
post #163
post #157

Earlier quoted context omitted.

Yes, generally people already use an additional tool for managing their Python executables, like their operating system's package manager: $> sudo apt-get install python3.10 python3.11 python3.12 And then it's simple to create and use version-specific virtual environments: $> python3.11 -m venv .venv3.11 $> source .venv3.11/bin/activate $> pip install -r requirements.txt You are incorrect about needing to use an addi…

> sudo apt-get install python3.10 python3.11 python3.12 This assumes the Python version you need is available from your package manager's repo. This won't work if you want a Python version either newer or older than what is available. > You are incorrect about needing to use an additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment. True, but it'…

>This assumes the Python version you need is available from your package manager's repo. This won't work if you want a Python version either newer or older than what is available.

And of course you could be working with multiple distros and versions of the same distro, production and dev might be different environment and tons of others concerns. You need something that just works across.

Re: Uv's killer feature is making ad-hoc environments easy

#179

Earlier quoted context omitted.

pip's resolving algorithm is not sound. If your Python projects are really simple it seems to work but as your projects get more complex the failure rate creeps up over time. You might pip install something and have it fail and then go back to zero and restart and have it work but at some point that will fail. conda has a correct resolving algorithm but the packages are out of date and add about as many quality probl…

May I introduce you to our lord and saviour, Nix and it's most holy child nixpkgs! With only a small tithing of your sanity and ability to Interop with any other dependency management you can free yourself of all dependency woes forever ! [ ] For various broad* definitions of forever. [*] Like, really, really broad** [**] Maybe a week if you're lucky

>May I introduce you to our lord and saviour, Nix and it's most holy child nixpkgs!

In this case, instead of working with Python, you change how you manage everything!

Re: Uv's killer feature is making ad-hoc environments easy

#180
post #61
post #20

Earlier quoted context omitted.

There’s a shebang now. as of PEP 722 you can declare dependencies in a comment at the top of a single file script that a package manager can choose to read and resolve. uv has support for it: https://docs.astral.sh/uv/guides/scripts/#running-a-script-w... (which only helps if your team is all in on uv, but maybe they are)

How does that work with the shebang?

  #!uv run
  # /// script
  # requires-python = ">=3.10"
  # dependencies = [
  #     "click>8",
  #     "rich",
  # ]
  # ///
and that's it
Post reply on HN