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

401–410 of 428 posts

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

#401

Post by rat87 »

meitham wrote: post #398
rat87 wrote: post #392

Earlier quoted context omitted.

Its not from some random github project its from a trusted member of open source community. Same as other libraries you use and install. It was used by rye before rye and uv sort of merged and is used by pipx and hatch and mise (and bazel rules_python) https://x.com/charliermarsh/status/1864042688279908459 My understanding is that the problem is that psf doesnt publish portable python binaries (I dont think they even…

That makes sense thanks for sharing these details

No problem.

That's not to say they aren't downsides. https://gregoryszorc.com/docs/python-build-standalone/main/q... documents them. As an example I had to add the https://pypi.org/project/gnureadline/ package to a work project that had its own auto completing shell because by default the builds replaces the gnu readline package with lived it/edit line and they're far from a drop in replacement.

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

#402

Post by remram »

zahlman wrote: post #375
remram wrote: post #355

Earlier quoted context omitted.

You can specify markers in the requirements file you write, not in the frozen requirements from 'pip freeze'. Because it's just a list of what's installed on your machine.

Running 'pip freeze' creates a plain text file. You can edit it to contain anything that would have been in "the requirements file you write". "Your requirements file" may or may not capture what it needs to, depending on how you created it. But Pip supports it. (And so does the `pyproject.toml` specification.)

You will need another tool to write a lock file that actually locks dependencies for more environments than your own. I don't know what you're trying to say. Pip does not support writing it.

Sure, I guess if you have one Pip will "support" reading it.

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

#403

Post by lmm »

mixmastamyk wrote: post #381
lmm wrote: post #307

Earlier quoted context omitted.

> It works fine until you upgrade to a new version of python, in which case you install the package again. Or you install a second global tool that depends on an incompatible version of a library.

Never happened, and exceedingly unlikely to because your user-wide tools should be few.

> exceedingly unlikely to because your user-wide tools should be few.

Why "should"? I think it's the other way around - Python culture has shied away from user-wide tools because it's known that they cause problems if you have more than a handful of them, and so e.g. Python profilers remain very underdeveloped.

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

#404

Post by jshen »

zahlman wrote: post #379
jshen wrote: post #356

Earlier quoted context omitted.

What's your process for ensuring all members of a large team are using the same versions of libraries in a non trivial python codebase?

If all you need to do is ensure everyone's on the same versions of the libraries - if you aren't concerned with your supply chain, and you can accept that members of your team are on different platforms and thus getting different wheels for the same version, and you don't have platform-specific dependency requirements - then pinned transitive dependencies are all the metadata you need. pyproject.toml isn't generally…

So you a re proposing to manually manage all transitive dependencies?

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

#405

Post by zahlman »

rat87 wrote: post #393
zahlman wrote: post #227

Earlier quoted context omitted.

I still don't understand why people want separate tooling to "handle the Python executable". All you need to do is have one base installation of each version you want, and then make your venv by running the standard library venv for that Python (e.g. `python3.x -m venv .venv`).

Lots of reasons starting. You may want many people to have the same point release. They have early builds without needing to compile it from source and have free threading (mogul) builds. I think they might even have pro builds. Not to mention that not all district releases will have the right python release. Also people want the same tool to handle both python version and venv creation and requirement installation

>Also people want the same tool to handle both python version and venv creation and requirement installation

This is the part I don't understand. Why should it be the same tool? What advantage does that give over having separate tools?

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

#406

Post by mixmastamyk »

lmm wrote: post #403
mixmastamyk wrote: post #381

Earlier quoted context omitted.

Never happened, and exceedingly unlikely to because your user-wide tools should be few.

> exceedingly unlikely to because your user-wide tools should be few. Why "should"? I think it's the other way around - Python culture has shied away from user-wide tools because it's known that they cause problems if you have more than a handful of them, and so e.g. Python profilers remain very underdeveloped.

There are simply few, I don't shy away from them. Other than tools replaced by ruff, httpie, twine, ptpython, yt-dlp, and my own tools I don't need anything else. Most "user" tools are provided by the system package manager.

All the other project-specific things go in venvs where they belong.

This is all a non-issue despite constant "end of the world" folks who never learned sysadmin and are terrified of an error.

If a libraries conflict, uninstall them, and put them in a venv. Why do all the work up front? I haven't had to do that in so long I forget how long it was. Early this century.

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

#407

Post by mixmastamyk »

TeMPOraL wrote: post #397
mixmastamyk wrote: post #385

Earlier quoted context omitted.

Not Debian specific. The braindead option was added by pip to scare off newbies. No one with the most basic of sysad skills is “bricked” by having to uninstall a library. Again have not experienced a conflict in over 15 years. Use the system package manager or buid yourself for tools like cmake.

Uninstalling a library - no. But I specifically mentioned trying to upgrade system Python, which is a quick way to break e.g. apt .

Ok, getting it now. I said upgrade python, and you thought I meant upgrade the system python in conflict with the distro. But that's not really what I meant. To clarify... I almost never touch the system python, but I upgrade the distro often. Almost every Ubuntu/Mint has a new system Python version these days.

So upgrade to new distro release, it has a new Python. Then pip install --user your user tools, twine, httpie, ruff, etc. Takes a few moments, perhaps once a year.

I do the same on Fedora, which I've been using more lately.

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

#408

Post by lmm »

mixmastamyk wrote: post #406
lmm wrote: post #403

Earlier quoted context omitted.

> exceedingly unlikely to because your user-wide tools should be few. Why "should"? I think it's the other way around - Python culture has shied away from user-wide tools because it's known that they cause problems if you have more than a handful of them, and so e.g. Python profilers remain very underdeveloped.

There are simply few, I don't shy away from them. Other than tools replaced by ruff, httpie, twine, ptpython, yt-dlp, and my own tools I don't need anything else. Most "user" tools are provided by the system package manager. All the other project-specific things go in venvs where they belong. This is all a non-issue despite constant "end of the world" folks who never learned sysadmin and are terrified of an error. If…

> This is all a non-issue despite constant "end of the world" folks who never learned sysadmin and are terrified of an error.

It's not a non-issue. Yes it's not a showstopper, but it's a niggling drag on productivity. As someone who's used to the JVM but currently having to work in Python, everything to do with package management is just harder and more awkward than it needs to be (and every so often you just get stuck and have to rebuild a venv or what have you) and the quality of tooling is significantly worse as a result. And uv looks like the first of the zillions of Python package management tools to actually do the obvious correct thing and not just keep shooting yourself in the foot.

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

#409

Post by 8n4vidtmkvmk »

nicoburns wrote: post #269
8n4vidtmkvmk wrote: post #266

Earlier quoted context omitted.

FWIW, you can usually just drop the `-g` and it'll install into `node_modules/.bin` instead, so it stays local to your project. You can run it straight out of there (by typing the path) or do `npm run ` which I think temporarily modifies $PATH to make it work.

The `npx` command (which comes bundled with any nodejs install) is the way to do that these days.

`npx` doesn't update package.json/package.lock though, right? So you might get a different version of the package once awhile. If it's an executable you depend on for your project, it makes sense to version it IMO.

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

#410

Post by nicoburns »

8n4vidtmkvmk wrote: post #409
nicoburns wrote: post #269

Earlier quoted context omitted.

The `npx` command (which comes bundled with any nodejs install) is the way to do that these days.

`npx` doesn't update package.json/package.lock though, right? So you might get a different version of the package once awhile. If it's an executable you depend on for your project, it makes sense to version it IMO.

You can do a (local) install using `npm install` and then execute the binary using `npx`. npx will also try to fetch the binary over the network if you don't have it installed, which is questionable behaviour in my opinion, but you can just cancel this if it starts doing it.
Post reply on HN