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

271–280 of 428 posts

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

#271

Post by tandav »

I'm waiting for this issue to be done: Add an option to store virtual environments in a centralized location outside projects https://github.com/astral-sh/uv/issues/1495

I have used virtualenvwrapper before and it was very convenient to have all virtual environments stored in one place, like ~/.cache/virtualenvs.

The .venv in the project directory is annoying because when you copy folder somewhere you start copying gigabytes of junk. Some tools like rsync can't handle CACHEDIR.TAG (but you can use --exclude .venv)

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

#272

Post by wombatpm »

nightpool wrote: post #183
coldtea wrote: post #178

Earlier quoted context omitted.

> 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.

Surely you just use Docker for production, right?

And how do you know everything is ok when you build your new docker image?

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

#273

Post by zahlman »

orf wrote: post #164
polski-g wrote: post #161

Earlier quoted context omitted.

"pip freeze" generates a lockfile.

No, that generates a list of currently installed packages . That’s very much not a lock file, even if it is possible to abuse it as such.

A list of currently installed packages in the current environment, with their exact versions. This is only the actually needed packages, with their transitive dependencies, unless you've left something behind from earlier in development. If you're keeping abstract dependencies up to date in `pyproject.toml` (which you need to do anyway to build and release the project), you can straightforwardly re-create the environment from that list and freeze whatever solution you get (after testing).

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

#274

Post by [deleted] »

shlomo_z wrote: post #190
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/

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.

[deleted]

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

#275

Post by matsemann »

zahlman wrote: post #242
ppierald wrote: post #184

Earlier quoted context omitted.

Respectively, yes. The ability to create venvs so fast, that it becomes a silent operation that the end user never thinks about anymore. The dependency management and installation is lightning quick. It deals with all of the python versioning and I think a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run Your script code would like: #!/usr/bin/env -S uv run --scri…

>Respectively, yes. The ability to create venvs so fast, that it becomes a silent operation that the end user never thinks about anymore. I might just blow your mind here: $ time python -m venv with-pip real 0m3.248s user 0m3.016s sys 0m0.219s $ time python -m venv --without-pip without-pip real 0m0.054s user 0m0.046s sys 0m0.009s The thing that actually takes time is installing Pip into the venv. I already have loca…

It's not the "runtime" that's slow for me with pip, but all the steps needed. My biggest gripe with python is you need to basically be an expert in different tools to get a random project running. Uv solves this. Just uv run the script and it works.

I don't care if pip technically can do something. The fact that I explicitly have to mess around with venvs and the stuff is already enough mental overhead that I disregard it.

I'm a python programmer at my job, and I've hated the tooling for years. Uv is the first time I actually like working with python.

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

#276

Post by benatkin »

comex wrote: post #250
benatkin wrote: post #120

Earlier quoted context omitted.

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 is…

As it happens, the Python REPL was just replaced a few months ago! …Not with IPython. But with an implementation written in Python instead of C, originating from the PyPy project, that supports fancier features like multi-line editing and syntax highlighting. See PEP 762. I was apprehensive when I heard about it, but then I had the chance to use it and it was a very nice experience.

Ooh, nice. I think recently the times I've used the latest version of python it's been with ipython, so I didn't notice. Going to check it out! It might be easier to make a custom repl now.

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

#277

Post by matsemann »

zahlman wrote: post #262
hyeonwho4 wrote: post #108

Earlier quoted context omitted.

This is not just a pip problem. I had the problem with anaconda a few years ago where upgrading the built in editor (spyder?) pulled versions of packages which broke my ML code, or made dependencies impossible to reconsile. It was a mess, wasting hours of time. Since then I use one pip venv for each project and just never update dependencies.

Spyder isn't built-in; IDLE comes with Python (unless you get it via Debian, at least), but is not separately upgradable (as the underlying `idlelib` is part of the standard library). If upgrading Spyder broke your environment, that's presumably because you were using the same environment that Spyder itself was in. (Spyder is also implemented in Python, as the name suggests.) However, IDEs for Python also like to try…

You're all over the thread defending the standard python tools, which is fine, it works for you. But the amount of times you've had to write that something is natively supported already or people is just using it wrong speaks volumes about why people prefer uv: it just works without having to learn loads of stuff.

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

#278

Post by zahlman »

phinnaeus wrote: post #199
driggs wrote: post #159

Earlier quoted context omitted.

The point is that if I'm writing a library and I specify `requests == 1.2.3`, then what are you going to do in your application if you need both my library and `requests == 1.2.4`? This is why libraries should not use lockfiles, they should be written to safely use as wide a range of dependencies' versions as possible. It's the developers of an application who should use a lockfile to lock transitive dependencies.

The lock file is for developers of the library, not consumers. Consumers just use the library’s dependency specification and then resolve their own dependency closure and then generate a lock file for that. If you, as a library developer, want to test against multiple versions of your dependencies, there are other tools for that. It doesn’t make lock files a bad idea in general.

As another library developer, of course I want to test against multiple versions. Or more accurately, I don't want to prevent my users from using different versions prematurely. My default expectation is that my code will work with a wide range of those versions, and if it doesn't I'll know - because I like to pay attention to other libraries' deprecations, just as I'd hope for my users to pay attention to mine.

Lockfiles aren't helpful to me here because the entire point is not to be dependent upon specific versions. I actively want to go through the cycle of updating my development environment on a whim, finding that everything breaks, doing the research etc. - because that's how I find out what my version requirements actually are, so that I can properly record them in my own project metadata. And if it turns out that my requirements are narrow, that's a cue to rethink how I use the dependency, so that I can broaden them.

If I had a working environment and didn't want to risk breaking it right at the moment, I could just not upgrade it.

If my requirements were complex enough to motivate explicitly testing against a matrix of dependency versions, using one of those "other tools", I'd do that instead. But neither way do I see any real gain, as a library developer, from a lock file.

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

#279

Post by zahlman »

mardifoufs wrote: post #238
BeefWellington wrote: post #211

Earlier quoted context omitted.

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 G…

It's more for either monorepos or in my case, to fix packages that have bugs but that I can't fix upstream. So for me, in my specific case, the freetype-py repo has a rather big issue with Unicode paths (it will crash the app if the path is in Unicode). There's a PR but it hasn't and probably won't get merged for dubious reasons. The easy choice, the one that actually is the most viable, is to pull the repo with the…

>The easy choice, the one that actually is the most viable, is to pull the repo with the patch applied, temporarily add it to my ./vendored folder and just ideally change the requirements.txt with no further changes (or need to create a new pypi package). But it's basically impossible since I just can't use relative paths like that.

You can use the repo's setup to build a wheel, then tell pip to install from that wheel directly (in requirements.txt, give the actual path/name of the wheel file instead of an abstract dependency name). You need a build frontend for this - `pip wheel` will work and that's more or less why it exists; but it's not really what Pip is designed for overall - https://build.pypa.io/en/stable/ is the vanilla offering.

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

#280

Post by zahlman »

o11c wrote: post #67
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?

Much of the Python ecosystem blatantly violates semantic versioning. Most new tooling is designed to work around the bugs introduced by this.

Relevant: https://iscinumpy.dev/post/bound-version-constraints/ Semver is hard; you never know what will break at least one of your users (see Hyrum's law), but on the other hand, clear backwards-compatibility breaks will often not affect a large fraction of users - if they preemptively declare that they won't support your next version, they may prevent Pip from finding a set of versions that would actually work just fine.
Post reply on HN