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

361–370 of 428 posts

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

#361

Post by mdaniel »

zahlman wrote: post #293
fny wrote: post #153

Earlier quoted context omitted.

Because you don’t need virtualenvs or ruby_modules. You can have however many versions of the same gem installed it’s simply referenced by a gemfile, so for Ruby version X you are guaranteed one copy of gem version Y and no duplicates. This whole installing the same dependencies a million times across different projects in Python and Node land is completely insane to me. Ruby has had the only sane package manager for…

In principle, venvs could hard-link the files from a common source, as long as the filesystem supports that. I'm planning to experiment with this for Paper. It's also possible to use .pth files ( https://docs.python.org/3/library/site.html ) to add additional folders to the current environment at startup. (I've heard some whispers that this causes a performance hit, but I haven't noticed. Python module imports are ca…

I wish the ecosystem made heavier use of .zip packages, which would gravely help with the logistics of your hardlink plan, in addition to slimming down 300MB worth of source code. The bad news is that (AIUI) the code needs to be prepared for use from a package and thus my retroactively just zipping them up will break things at runtime

Take for example:

  $ du -hs $HOMEBREW_PREFIX/Cellar/ansible/11.1.0_1/libexec/lib/python3.13/site-packages/* | gsort --human
  103M /usr/local/Cellar/ansible/11.1.0_1/libexec/lib/python3.13/site-packages/botocore
  226M /usr/local/Cellar/ansible/11.1.0_1/libexec/lib/python3.13/site-packages/ansible_collections

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

#362

Post by PaulHoule »

vlovich123 wrote: post #154
PaulHoule wrote: post #97

Earlier quoted context omitted.

... it's tricky. In Java there's a cultural expectation that you name a package like package organization.dns.name.this.and.that; but real scalability in a module system requires that somebody else packages things up as package this.and.that; and you can make the system look at a particular wheel/jar/whatever and make it visible with a prefix you specify like package their.this.and.that; Programmers seem to hate rigo…

> Programmers seem to hate rigorous namespace systems though Pretty much a nothing burger in Rust, so I disagree that items necessarily hate the concept. Maybe others haven’t done a good job with the UX?

That. Forcing people to do it right from day one helps a lot. Also Rust attracts a programmer who is willing to accept some pain up front to save pain later, if your motto is "give me convenience or give me death" you might stick with C or Python.

If you give people an "easy way out" it is very hard to compel them to do it more rigorously. Look at the history of C++ namespaces as well as the non-acceptance of various "Modula" languages and Ada back in the 1980s.

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

#363

Post by randomlurking »

Zizizizz wrote: post #326
shlomo_z wrote: post #190

Earlier quoted context omitted.

Is it possible for my IDE (vscode) to support this? Currently my IDE screams at me for using unknown packages and I have no type hinting, intellisense, etc.

With your python plugin you should be able choose .venv/bin/python as your interpreter after you've run `uv sync` and everything should resolve

So it doesnt work wirk adhoc venvs, does it? Might still valuable for simply running scripts, but I’m not sure venv-less works for dev

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

#364

Post by bityard »

meitham wrote: post #252
bityard wrote: post #200

I usually stay away far FAR from shiny new tools but I've been experimenting with uv and I really like it. I'm a bit bummed that it's not written in Python but other than that, it does what it says on the tin. I never liked pyenv because I really don't see the point/benefit building every new version of Python you want to use. There's a reason I don't run Gentoo or Arch anymore. I'm very happy that uv grabs pre-compi…

uv is great, but downloading and installing base python interpreter is not a good feature as it doesn’t fetch that from PSF but from a project on GitHub, that very same project says this is compiled for portability over performance, see https://gregoryszorc.com/docs/python-build-standalone/main/

But PSF doesn't distribute binary builds, so what's the alternative?

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

#365

Post by dagw »

meitham wrote: post #256
worik wrote: post #130

Earlier quoted context omitted.

> Python has been cleaning up a number of really lethal problems like I wish they would stick to semantic versioning tho. I have used two projects that got stuck in incompatible changes in the 3.x Python. That is a fatal problem for Python. If a change in a minor version makes things stop working, it is very hard to recommend the system. A lot of work has gone down the drain, by this Python user, trying to work aroun…

I assume these breaking changes are in the stdlib and not in the python interpreter (the language), right? There was previous discussions about uncoupling the stdlib (python libraries) from the release and have them being released independently, but I can’t remember why that died off

I assume these breaking changes are in the stdlib

Well yes, but sometimes the features provided by stdlib can feel pretty 'core'. I remember that how dataclasses work for example changed and broke a lot of our code when we upgraded from 3.8 to 3.10,

There have also been breaking changes in the C API. We have one project at work that is stuck at 3.11 since a third party dependency won't build on 3.12 without a rewrite.

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

#366

Post by meitham »

bityard wrote: post #364
meitham wrote: post #252

Earlier quoted context omitted.

uv is great, but downloading and installing base python interpreter is not a good feature as it doesn’t fetch that from PSF but from a project on GitHub, that very same project says this is compiled for portability over performance, see https://gregoryszorc.com/docs/python-build-standalone/main/

But PSF doesn't distribute binary builds, so what's the alternative?

it does of course here https://www.python.org/downloads/ or are you referring to linux?

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

#367

Post by meitham »

brainzap wrote: post #336
meitham wrote: post #252

Earlier quoted context omitted.

uv is great, but downloading and installing base python interpreter is not a good feature as it doesn’t fetch that from PSF but from a project on GitHub, that very same project says this is compiled for portability over performance, see https://gregoryszorc.com/docs/python-build-standalone/main/

that it does it automatically is weird

I've only noticed after my corporate firewall stopped me!

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

#368

Post by zahlman »

CGamesPlay wrote: post #357
zahlman wrote: post #308

Earlier quoted context omitted.

It's not "some sort of technical distinction". Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment. Usually, you can directly make a pre-built wheel, and then an installer like Pip or uv can just unpack that into the environment. If it needs to be build on the user's machine…

Maybe the docs are misleading? Seems that if I want my package to be installed, I need to pick a build system, regardless of if I am using any native code. https://docs.astral.sh/uv/concepts/projects/init/#packaged-a... > Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment.…

>Seems that if I want my package to be installed, I need to pick a build system, regardless of if I am using any native code.

If you want to distribute it to be installable by others, yes. Except that at least for now, installers will assume Setuptools by default if you don't mention anything in your `pyproject.toml`.

>but to me, as a Python developer who wants to be able to publish a pure Python CLI program to PyPI,

If you're making pure Python projects, the actual build process is trivial and every build system will do just fine. But again, the build system you choose builds your code, not your external dependencies. Whatever you put in `pyproject.toml` here has nothing to do with the packages that you install. It has to do with other people installing your package (and you taking steps to make that easier). So "external dependencies don't build the same as on Poetry" makes no sense in this context. If you need to build external dependencies (i.e. they don't come pre-built for your system), they will automatically be built with the build system that they choose.

>it seems like a distinction without a difference.

Let me try again: When you use a package manager, it's so that you can keep track of which code from other people you're using. When you choose a build system and mention it in `pyproject.toml`, it's so that other people can use your code. (For your pure Python project, you will normally run the build system locally - https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pure-... . But the overall packaging ecosystem is designed so that you can push part of that work onto the end user, when it makes sense to do so.)

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

#369

Post by dagw »

CGamesPlay wrote: post #217

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…

Uv doesn't include a "build system", but encourages you to use some other one.

Personally I consider this one of uv's greatest strengths. The inflexibility and brittleness of Poetry's build system is what made me give up on poetry entirely. Had poetry made it easy to plug in a different build system I might never have tried uv.

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

#370

Post by meitham »

mkl wrote: post #344
meitham wrote: post #245

Earlier quoted context omitted.

I would avoid using this feature! It downloads a compiled portable python binary from some random github project not from PSF. That very same github project recommends against using their binary as the compilation flags is set for portability against performance. See https://gregoryszorc.com/docs/python-build-standalone/main/

https://github.com/astral-sh/python-build-standalone is by the same people as uv, so it's hardly random. The releases there include ones with profile-guided optimisation and link time optimisation [1], which are used by default for some platforms and Python versions (and work seems underway to make them usable for all [2]). I don't see any recommendation against using their binaries or mention of optimising for porta…

This must have moved recently! I looked at this around end of December and it was hosted on https://github.com/indygreg/python-build-standalone/releases which had nothing to do with UV. If you read through the docs now it still references indygreg and still shows this https://github.com/indygreg/python-build-standalone so I guess the move has not completed it, but yes it's a positive change to see UV taking ownership of the builds.
Post reply on HN