Discussion
Search code, repositories, users, issues, pull requests...
trollbridge: Looks great, and in particular, uv’s cache growing forever and lack of the uv shell command were both maddening.I assume mainstream uv development will go into maintenance mode now, so it’s great to see a quality lineage like this.
Bender: Given the telemetry, how did uv ever get approved/adopted by the open source community to begin with, or did it creep in? Why isn't it currently burning in a fire?
worksonmine: Why prefix the settings `UV_CACHE_MAX_SIZE` and `UV_LOCKFILE` with `UV_` if they're new features? Makes no sense.
albinn: The shell and upgrade commands are helpful, especially when onboarding someone who has not used uv before.Crazy that there is not way in uv to limit the cache size. I have loved using uv though, it is a breath of fresh air.
unethical_ban: Facilitates drop-in migration from uv to the new tool. So if uv adopts the feature it's "just there".
_flux: They are environment variables. I enjoy seeing from my large number of environment variables to which applications they belong to.
worksonmine: I know what an environment variable is, my question is why name them `UV_` instead of `FYN_`? I thought that would've been obvious for exactly the same reason you mention, it should be named for the application they belong to.
add-sub-mul-div: Because not everyone has a knee-jerk emotional reaction to a word when that word can mean something benign aside from its typical FUD connotation.
fmajid: I'm worried about OpenAI enshittifying uv and ruff now they've acquired Astral, so it's good to have options.
_flux: Ah, I completely missed the point of your question :).Yes, I think that's a good point. Possibly they were made before the project name was changed and no further thought was given to them after.
Bender: I will always have a "knee-jerk" response to opt-out or mandatory telemetry or any other outbound connections I did not ask for being initiated automatically. In a corporate world I would have to block this and depending on what the telemetry is connecting to that could impact other outbound connections leading to contention without the org.One of the right ways to do this would be to opt-in by setting an environment variable to enabled any combination of extra debugging, telemetry, stats, etc...
dirkc: I suspect that my normal workflows might just have evolved to route around the pain that package management can be in python (or any other ecosystem really).In what situations are uv most useful? Is it once you install machine learning packages and it pulls in more native stuff - ie is it more popular in some circles? Is there a killer feature that I'm missing?
politelemon: Imo, uv scripts with the dependencies in the header.https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
dec0dedab0de: UV is most useful because it is so much faster than everything else. All the other features I could do without.
lr1970: From fyn's roadmap:> 2. Centralized venv storage — keep .venvs out of your project dirsI do not like this. virtual environments have been always associated with projects and colocated with them. Moving .venv to centralized storage recreates conda philosophy which is very different from pip/uv approach.In any case, I am using pixi now and like it a lot.
simonw: Here's where that feature was (and is still being) discussed in the uv repo: https://github.com/astral-sh/uv/issues/1495It's been open for two years but it looks like there's a PR in active development for it right now: https://github.com/astral-sh/uv/pull/18214
Levitating: It has been working fine for build systems like cargo.
derodero24: As someone shipping native Node addons, registry telemetry (OS, arch, platform) is one of the few ways I know which build targets to actually prioritize. Without it I'd be guessing whether anyone's even using linux-arm64-musl. I get the instinct to strip it, but for package maintainers it's genuinely useful data.
dec0dedab0de: thats my biggest problem with uv, i liked the way pipenv did it much better. I want to be able to use find and recursive grep without worrying that libraries are in my project directory.uv is just so fast that i deal with it.
imcritic: How is pixi better than uv?
lr1970: > How is pixi better than uv?pixi is a general multi-languge, multi-platform package manager. I am using it now on my new macbook neo as a homebrew _replacement_. Yes, it goes beyond python and allows you to install git, jj, fzf, cmake, compilers, pandoc, and many more.For python, pixi uses conda-forge and PyPI as package repos and relies on uv's rattler dependency resolver. pixi is as fast as uv (it uses fast code path from uv) but goes further beyond python wheels. For detail see [0] or google it :-)[0] https://pixi.prefix.dev/latest/
nilslindemann: [delayed]
maverwa: If I understand the description of this „telemetry“ in fyns „MANIFESTO.md“ correctly, it does not make outbound connections you did not asked for. It sets the user agent http header to something that identifies your OS, CPU, python version and if you are running in Ci when communicating to the package registry. It does not send any of that to astral, not ist any of that highly personal.Sure, it should not be there by default, especially OS & CPU imho. But it’s not really what I’d call „invasive telemetry“.
arjie: > These things include your OS, py version, CPU architecture, Linux distro, whether you're in CI. All baked into the User-Agent header via something called "linehaul". We ripped that out. Now it just sends fyn/0.10.13. That's it.I imagine it's just that the User-Agent is something that we've grown accustomed to passing information in. I am fairly biased since I'd always opt-in even to popcon. I think it's useful to have such usage information.
PurpleRamen: This is so useful, I'm shocked they even make a big thing out of it. And now I'm questioning whether this is even their real intention, or just a diversion?
dirkc: I guess that could be useful. I don't have many standalone python scripts, and those that I do have are very basic. It would be really nice if that header could include sandboxing!
simonw: If you have hundreds of different Python projects on your machine (as I do) the speed and developer experience improvements of uv make a big difference.I love being able to cd into any folder and run "uv run pytest" without even having to think about virtual environments or package versions.
dirkc: Do you run those projects on the host system as your normal user without any isolation?
simonw: Yes, which makes me very vulnerable to supply chain attacks.
dirkc: Yikes! I had a scare once, and since then I only run sandboxed code or scripts I've written with minimal 3rd party deps.I assume you have other mitigations in place?
simonw: So much this! I've been bugging Astral about addressing the sandboxing challenge for a while, I wonder if that might take more priority now they're at OpenAI?
simonw: Not really. I have good backups and I try to stick with dependencies I trust.I do a lot of my development work using Claude Code for web which means stuff runs in containers on Anthropic's servers, but I run things on my laptop most days as well.
