zanie

I don't think it's true at all that "dropping features" makes uv fast. As an author of uv, I think that particular section of the article is way off base.

(I work on uv)

As a note, you can set the default bounds for `uv add` in persistent configuration — no need to provide it every time. See https://docs.astral.sh/uv/reference/settings/#add-bounds

We prefer not to add upper bounds by default because it causes a lot of unnecessary conflicts in the ecosystem. I previously collected some resources on this back when I used Poetry :) see https://github.com/zanieb/poetry-relax#references

I'm a bit confused, `uv run --with $package main --help` should do what you say with very little overhead. We won't reinstall it every time, `--with` environments are stored in the cache and retained. Even if the environment is cached, the dependency is cached and installing from the cache is very fast (<200ms for sure).

Please feel free to open a reproduction with details and we can look into it.

(I work on uv)

fwiw `uv upgrade` is on the roadmap — we just haven't done it yet because it's hard to build a great experience for it (there are far more nuances than people expect) and we're a small team with a lot of priorities.

We do address this in the article! It's defense in depth, not theater.

We audit all of our actions, check if they pull in mutable dependencies, contribute upstream fixes, and migrate off using any action when we can.

(I work at Astral)

A brief note, your numbers are way off here — Astral subsequently raised a Series A and B (as mentioned in the blog post) but did not announce them. We were doing great financially.

(I work at Astral)

Ruff wasn't named after the bird, we just think it's funny that Charlie didn't know it was a bird. He made up the word :)

This is also documented at https://github.com/astral-sh/ty?tab=readme-ov-file#contribut... and https://github.com/astral-sh/ty/blob/main/CONTRIBUTING.md#re...

As noted in the linked issue

At time of writing, many of the remaining rules require type inference and/or multi-file analysis, and aren't ready to be implemented in Ruff.

ty is actually a big step in this direction as it provides multi-file analysis and type inference.

(I work at Astral)

You're upset that uv doesn't yet support something that no other tool in the ecosystem supports?

I'd love for uv to lock build dependencies, but due to the dynamic nature of Python package metadata it's quite a hard problem. It'll be supported eventually though.

(I work on uv)

It's intentionally distinct from the `uv tool` interface — it won't change `ruff` or `uv tool run` behaviors.

Thanks that's helpful.

Did you try reducing the concurrency limit?

Please open an issue with some details about the memory usage. We're happy to investigate and feedback on how it's working in production is always helpful.

(I work on uv)

Thanks for the feedback!

Yes, we let you override our detection of your hardware. Though we haven't implemented dumping detected information on one platform for use on another, it's definitely feasible, e.g., we're exploring a static metadata format as a part of the wheel variant proposal https://github.com/wheelnext/pep_xxx_wheel_variants/issues/4...

It's actually not powered by Wheel Variants right now, though we are generally early adopters of the initiative :)

We're hoping that building a commercial service makes it clear that we have a sustainable business model and that our tools (like uv) will remain free and permissively licensed.

(I work at Astral)

If you open even a brief issue and tag me @zanieb I'm happy to take a look!

We consider it a breaking change to switch the default, so that's coming a bit later.

Installation in Docker just looks like

    COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/

(We'd recommend pinning the version or SHA in production)

ty doesn't invoke a Python interpreter to discover imports yet — so you need to either set `VIRTUAL_ENV` or pass `--python` to configure your target environment. We'll expand support here in the future, but this part of ty's interface is intentionally minimal while we focus on core type checking features.

The plan remains the same as when the company was announced (https://astral.sh/blog/announcing-astral-the-company-behind-...) — paid services that build on and integrate with the free tooling.

ditto! but we gave impressively non-overlapping answers

As in, how are we parsing the Python code into an AST?

CPython uses a generated parser. The grammar is defined in https://github.com/python/cpython/blob/main/Grammar/python.g... which is used to generate the specification at https://docs.python.org/3/reference/grammar.html#full-gramma...

We use a hand-written parser, in Rust, based on the specification. We've written that previously at https://astral.sh/blog/ruff-v0.4.0#a-hand-written-parser

It'll be separate (at least to start) — we want to be able to iterate on it rapidly. Long-term, a consistent toolchain is definitely important and something we're thinking about.

:wave:

Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :)

Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready.

Stay tuned for more for news in the near future!

(... I work at Astral)

Hi! I work on the Python distributions uv uses. Performance is really important to us and we're on the bleeding edge of performant Python builds. Our distributions use profile guided optimization (PGO) as well as post-link optimizations (BOLT). From my understanding, these are not enabled by pyenv by default because they significantly increase build times. It's possible there are some platform-specific build benefits, but I'd be surprised if it was significant.

I can set up some benchmarks comparing to pyenv on a couple common platforms – lately I've just been focused on benchmarking changes to CPython itself.

Yeah uv uses a platform independent resolution for its lockfiles supports features that Poetry does not, like

- Specifying a subset of platforms to resolve for

- Requiring wheel coverage for specific platforms

- Conflicting optional dependencies

https://docs.astral.sh/uv/concepts/resolution/#universal-res...

https://docs.astral.sh/uv/concepts/projects/config/#conflict...

It's a joke about how Charlie didn't know Ruff was a bird.

https://en.wikipedia.org/wiki/Red_knot

Thanks!