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

211–220 of 428 posts

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

#211

Post by BeefWellington »

mardifoufs wrote: post #147
BeefWellington wrote: post #70

Earlier quoted context omitted.

Sure you can. It's in their example for how to use requirements.txt: https://pip.pypa.io/en/stable/reference/requirements-file-fo... Maybe there's some concrete example you have in mind though?

I don't think so, though maybe I didn't explain myself correctly. You can link to a relative package wheel I think, but not to a package repo. So if you have a repo, with your main package in ./src, and you vendor or need a package from another subfolder (let's say ./vendored/freetype) , you can't actually do it in a way that won't break the moment you share your package. You can't put ./vendored/freetype in your req…

In this scenario, reading between the lines, the vendor is not providing a public / published package but does provide the source as like a tarball?

I have yet to run into that particular case where the vendor didn't supply their own repo in favour of just providing the source directly. However I do use what are essentially vendor-supplied packages (distant teams in the org) and in those cases I just point at their GitLab/GitHub repo directly. Even for some components within my own team we do it this way.

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

#212

Post by __MatrixMan__ »

stevage wrote: post #26

As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.

I think it makes sense given that people using python to write applications are a minority of python users. It's mostly students, scientists, people with the word "analyst" in their title, etc. Perhaps this goes poorly in practice, but these users ostensibly have somebody else to lean on re: setting up their environments, and those people aren't developers either.

I have to imagine that the python maintainers listen for what the community needs and hear a thousand voices asking for a hundred different packaging strategies, and a million voices asking for the same language features. I can forgive them for prioritizing things the way they have.

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

#213

Post by geethree »

mdaniel wrote: post #132
cdaringe wrote: post #41

Earlier quoted context omitted.

Hot take: pnpm is the best dx, of all p/l dep toolchains, for devs who are operating regularly in many projects. Get me the deps this project needs, get them fast, then them correctly, all with minimum hoops. Cargo and deno toolchains are pretty good too. Opam, gleam, mvn/gradle, stack, npm/yarn, nix even, pip/poetry/whatever-python-malarkey, go, composer, …what other stuff have i used in the past 12 months… c/c++ do…

I swear I'm not trolling: what do you not like about modern golang's dep management (e.g. go.mod and go.sum)? I agree that the old days of "there are 15 dep managers, good luck" was high chaos. And those who do cutesy shit like using "replace" in their go.mod[1] is sus but as far as dx $(go get) that caches by default in $XDG_CACHE_DIR and uses $GOPROXY I think is great 1: https://github.com/opentofu/opentofu/blob/v1…

To be fair your specific example is due to… well forking terraform due to hashicorp licensing changes.

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

#214

Post by stevage »

__MatrixMan__ wrote: post #212
stevage wrote: post #26

As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.

I think it makes sense given that people using python to write applications are a minority of python users. It's mostly students, scientists, people with the word "analyst" in their title, etc. Perhaps this goes poorly in practice, but these users ostensibly have somebody else to lean on re: setting up their environments, and those people aren't developers either. I have to imagine that the python maintainers listen…

I'm not sure I understand your point. Managing dependencies is easy in node. It seems to be harder in Python. What priority is being supported here?

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

#215

Post by diath »

driggs wrote: post #157
NeutralCrane wrote: post #43

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…

That assumes that you are using a specific version of a specific Linux distribution that happens to ship specific versions of Python that you are currently targeting. That's a big assumption. uv solves this.

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

#216

Post by mdaniel »

geethree wrote: post #213
mdaniel wrote: post #132

Earlier quoted context omitted.

I swear I'm not trolling: what do you not like about modern golang's dep management (e.g. go.mod and go.sum)? I agree that the old days of "there are 15 dep managers, good luck" was high chaos. And those who do cutesy shit like using "replace" in their go.mod[1] is sus but as far as dx $(go get) that caches by default in $XDG_CACHE_DIR and uses $GOPROXY I think is great 1: https://github.com/opentofu/opentofu/blob/v1…

To be fair your specific example is due to… well forking terraform due to hashicorp licensing changes.

hcl is still MPLv2 https://github.com/hashicorp/hcl/blob/v2.23.0/LICENSE and my complaint is that the .go file has one import path but the compiler is going to secretly use a fork, versus updating the import path like a sane person. The only way anyone would know to check for why the complied code behaves differently is to know that trickery was possible

And that's not even getting into this horseshit: https://github.com/opentofu/hcl/blob/v2.20.1/go.mod#L1 which apparently allows one to declare a repos _import_ path to be different from the url used to fetch it

I have a similar complaint about how in the world anyone would know how "gopkg.in/yaml.v3" secretly resolved to view-source:https://gopkg.in/yaml.v3?go-get=1

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

#217

Post by CGamesPlay »

I want to like uv, but unfortunately there's some kind of technical distinction between a Python "package manager" and a "build system". Uv doesn't include a "build system", but encourages you to use some other one. The net result is that external dependencies don't build the same as on Poetry, don't work, and uv points the finger at some other dependency.

I do hope the situation changes one day. Python packaging is such a mess, but Poetry is good enough and actually works, so I'll stick with it for now.

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

#218

Post by rat87 »

poincaredisk wrote: post #14
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…

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

Pip is sort of broken before because it encourages confusion between requirements and lock files. In other languages with package managers you generally specify your requirements with ranges and get a lock file with exact versions of those and any transitive dependencies letting you easily recreate a known working environment. The only way to do that in pip is to make a *new* venue install then pip freeze. I think pip tools package is supposed to help but it's a separate tool (one which I've also includes). Also putting stuff in pyproject.toml feels more solid then requirements files (and allows options to be set on requirements (like installing only one package that's only on your company's private python package index mirror while installing the others from the global python package index) and allows dev dependencies and other optional features dependency groups without multiple requirements files and having to update locks on those files.

It also automatically creates venvs if you delete them. And it automatically updates packages when you run something with uv run file.py (useful when somebody may have updated the requirements in git). It also lets you install self contained (installed in a virtualenv and linked to ~/.local/bin which is added to your path)python tools (replacing pipx). It installs self contained python builds letting you more easily pick python version and specify it in a .python-version file for your project (replacing pyenv and usually much nicer because pyenv compiles them locally)

Uv also makes it easier to explore and say start a ipython shell with 2 libraries uv run --with ipython --with colorful --with https ipython

It caches downloads. Of course the http itself isn't faster but they're exploring things to speed that part up and since it's written in rust local stuff (like deleting and recreating a venv with cached packages) tends to be blazing fast

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

#219

Post by blibble »

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.

with that expected use case of uv script run command it effectively makes those comments executable

python's wheels are falling off at an ever faster and faster rate

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

#220

Post by fastball »

stevage wrote: post #26

As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.

Environment and dependency management in JS-land is even worse.

Similar problems with runtime version management (need to use nvm for sanity, using built-in OS package managers seems to consistently result in tears).

More package managers and interactions (corepack, npm, pnpm, yarn, bun).

Bad package interop (ESM vs CJS vs UMD).

More runtimes (Node, Deno, Bun, Edge).

Then compound this all with the fact that JS doesn't have a comprehensive stdlib so your average project has literally 1000s of dependencies.

Post reply on HN