Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

valatka.dev

Post reply on HN
Print view View original

111–120 of 428 posts

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

#111

Post by mrbonner »

nharada wrote: 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…

+1 uv now also supports system installation of python with the --default --preview flags. This probably allows me to replace mise (rtx) and go uv full time for python development. With other languages, I go back to mise.

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

#112

Post by linsomniac »

aeurielesn wrote: post #96
riwsky wrote: post #52

Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

I don't understand how things like this get approved into PEPs.

I don't think this IS a PEP, I believe it is simply something the uv tool supports and as far as Python is concerned it is just a comment.

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

#114

Post by crispyambulance »

I do like uv and hope to try it soon but I don't get the point of the article.

Pyenv + poetry already gives you ability to "pull in local dependencies". Yes, you have to create a virtual environment and it's not "ad-hoc".

But if you're going to pull in a bunch of libraries, WHY would you want to invoke python and all your work dependencies on a one liner? Isn't it much better and easier to just spell-out the dependencies in a pyproject.toml? How "ad-hoc" are we talking here?

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

#115

Post by driggs »

n144q wrote: post #100
zo1 wrote: post #71

Earlier quoted context omitted.

The requirements.txt file is the lockfile. Anyways, this whole obsession with locked deps or "lockfiles" is such an anti-pattern, I have no idea why we went there as an industry. Probably as a result of some of the newer stuff that is classified as "hipster-tech" such as docker and javascript.

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.

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

#116

Post by loxias »

mosselman wrote: post #27
poincaredisk wrote: post #14

Earlier quoted context omitted.

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

I am not a python developer, but sometimes I use python projects. This puts me in a position where I need to get stuff working while knowing almost nothing about how python package management works. Also I don’t recognise errors and I don’t know which python versions generally work well with what. I’ve had it happen so often with pip that I’d have something setup just fine. Let’s say some stable diffusion ui. Then so…

My life got a lot easier since I adopted the habit of making a shell script, using buildah and podman, that wrapped every python, rust, or golang project I wanted to dabble with.

It's so simple!

Create a image with the dependencies, then `podman run` it.

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

#117

Post by mdaniel »

andrewmcdonough wrote: post #92
mdaniel wrote: post #35

Earlier quoted context omitted.

Caveat: I'm a node outsider, only forced to interact with it But there are a shocking number of install instructions that offer $(npm i -g) and if one is using Homebrew or nvm or a similar "user writable" node distribution, it won't prompt for sudo password and will cheerfully mangle the "origin" node_modules So, it's the same story as with python: yes, but only if the user is disciplined Now ruby drives me fucking b…

Ruby has a number of solutions for this - rvm (the oldest, but less popular these days), rbenv (probably the most popular), chruby/gem_home (lightweight) or asdf (my personal choice as I can use the same tool for lots of languages). All of those tools install to locations that shouldn't need root.

Yes, I am aware of all of those, although I couldn't offhand tell anyone the difference in tradeoffs between them. But I consider having to install a fresh copy of the whole distribution a grave antipattern. I'm aware that nvm and pyenv default to it and I don't like that

I did notice how Homebrew sets env GEM_HOME=/libexec GEM_PATH=/libexec (e.g. https://github.com/Homebrew/homebrew-core/blob/9f056db169d5f...>) but, similar to my node experience, since I am a ruby outsider I don't totally grok what isolation that provides

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

#118

Post by philomath_mn »

sonium wrote: post #101

But I still need pip to install uv, right? Or download it using a one-liner alternatively.

You can install it in several ways without pip, easiest is standalone installer (which can upgrade itself)

https://docs.astral.sh/uv/getting-started/installation/

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

#119

Post by epistasis »

aeurielesn wrote: post #96
riwsky wrote: post #52

Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

I don't understand how things like this get approved into PEPs.

The PEP page is really good at explaining the status of the proposal, a summary of the discussion to date, and then links to the actual detailed discussion (in Discourse) about it:

https://peps.python.org/pep-0723/

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

#120

Post by benatkin »

nharada wrote: 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…

This:

> I haven't felt like it's a minor improvement on what I'm using

means that this:

> I'd love if we standardized on it as a community as the de facto default

…probably shouldn’t happen. The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way.

It would be like replacing the python repl with the current version of ipython. I’d say the same thing, that it isn’t a minor improvement. While I almost always use ipython now, I’m glad it’s a separate thing.

Post reply on HN