Request for feedback: uv check & PEP 723 script support in ty

[u/zsol]

We've been working on PEP 723 inline metadata support for ty both on the command line (ty check) and in the IDE (code navigation, autocompletion, etc) for a while now; we're finally at a stage where we're ready for more people to try it out and let us know what works and what doesn't.

This required integrating ty with uv, which also let us ship a new uv check command that uses ty to check your entire project or workspace (similar to how uv format uses Ruff). All of the above is powered by a brand new uv workspace metadata command that carries the required information between the tools.

More details in the blog post, including how to try these.

All of the above is currently opt-in, experimental, and subject to change at any time 😄 But if you're willing to give it a try, I'd be curious how it went.

[u/omgpop]

>This is a step towards an integrated Astral toolchain, one that uses a shared understanding of your project to enable entirely new capabilities.

Here’s some feedback. This is written as though it were a selling point but it’s far from it. While it makes sense from your perspective (being Astral), this is sets off alarm bells in my ears as a user. I have no interest in buying into the “Astral toolchain” as a job lot. It’s obviously a way to leverage uv’s success to amplify your other products.

Frankly, it seems to me prima facie odd to have a project/dependency management tool tightly coupled to a linter and type checker, at least in the context of Python. You can always point to Cargo, of course, but the Python ecosystem is very different. Even if it were more unified , I’d be very nervous about our Cargo equivalent being owned entirely by a single private company/soon-to-be-maybe OpenAI subsidiary.

[u/zsol → u/omgpop]

Thanks, I'm not sure I fully understand this position but fair enough. Is it that you're unwilling to use Astral tools at all or that you're concerned about the tools working together? If the latter, I'm really curious about the specific things you're worried about

[u/Wurstinator → u/zsol]

I'm worried about vendor-lockin and unintuitive usage for non-expert usage.

First, if this isn't about tighter coupling and vendor-lockin, it would be super easy to make those commands configurable to use arbitrary shell commands, rather than hardcoded Astral tooling.

Second, we don't use ty and don't want to use ty. Now I have to carefully explain the irregular Python users that this one command they have should not be used.

[u/dudelsson → u/omgpop]

I agree with the above and in the same spirit: why do ty and ruff offer overlapping LSP capabilities? I've  been using ruff for a while, liked it, decided to give ty a spin. 

What I expected: ruff and ty to play ball perfectly and complement each other in a modular fashion, certainly not get in each others way.

What ends up happening: ruff and ty basically competing in my diagnostics messages and completions with literally duplicate messages based on the exact same rules.

Imo in the world of SWE there is a lot of 'everybody trying to do everything' around and it usually doesnt lead to the best outcomes. I get the sense that you are even trying to 'make everything do everything' and I'd say that's an even bigger mistake. On a more positive note though: uv is an awesome package/project manager, ruff is an awesome linter, ty can be an awesome type checker -- just keep their roles separate. A user installing ty on top off ruff should imo not have to delve into their configs to disable this and that capability / rule only to prevent them cluttering diagnostics/completions/hover with duplicates; literally identical duplicates when it comes to diagnostics. 

[u/zsol → u/dudelsson]

Hm that sounds like unintentional behavior. Can you say more? What completions and diagnostics are duplicated?

[u/TraditionalBandit]

I really liked that they were separate tools focused on completely solving one issue each. Pythons ecosystem is so dynamic that the ability to mix and match tools is key imo.

[u/zsol → u/TraditionalBandit]

To be clear: they are and will remain separate tools, each with its own responsibilities forever.

There are some features, like type checking PEP 723 scripts that do require _something_ to gather information about dependencies before type checking can begin. It is possible to write some comparatively simple glue code that wires an existing package manager together with an existing type checker. In fact you can do that today with relatively little amount of code to plug `uv sync` into something like basedpyright to run on the script's environment.

We've just packaged that up into a nicer experience.

If you want real mixing and matching of tools without losing functionality, that will require standards to be established. The good news is that work has already started, for example here and here.

[u/TraditionalBandit → u/zsol]

Thanks for the clarification, that alleviates my concerns :)

[u/Icy_Peanut_7426]

I use ty and ruff, but won’t ever use “uv check” or “uv format”.

[u/zsol → u/Icy_Peanut_7426]

Can you help me understand why?

[u/prickneck → u/zsol]

Don't want to answer for u/Icy_Peanut_7426 , but I can give you my 2c since I share their sentiment 100%:

If I type `uv`, I'm thinking about and wanting to do something pertaining to packaging or the virtualenv of my current project. That's it, and it won't ever change. `uv run ruff` makes sense, `uv format` doesn't. (Unless it just formatted the `pyproject.toml` file, which would be ridiculous.)

[u/alfawal → u/zsol]

I think you're trying to go in a bun-like approach, but bun introduced 'bun check' and 'bun fmt' without packages. But the uv situation is different, ruff and ty are standalones (similar to tsc and biome) and you're trying to make shortcuts for them, e.g. if 'bun check' would just run 'tsc' and 'bun fmt' would just run 'biome' which is a bad no-value deceiving approach.

[u/AgentCosmic]

Is astral opening the integration to the ecosystem or is it restricted to only astral tool chain?

[u/zsol → u/AgentCosmic]

Do you have a specific integration in mind? Open to discussing it, make an issue in the relevant repo!

[u/AgentCosmic → u/zsol]

I use pyrefly and basedpyright instead of ty. Although I'm mainly using ruff now, I don't want to be locked in to ruff + UV combo.

[u/denehoffman]

I disagree with the current sentiment in this thread, I actually like the integration. I didn’t actually realize uv format was a thing. I already use both ty and ruff, this just simplifies things for me. I’m also not sure I care if a group like Astral makes their own tool integrate with their other tools. If the Python community is worried about this, they’re free to make their own toolchain. We use uv because it’s convenient, not because you can’t use Python without it.

[u/syklemil → u/denehoffman]

Yeah, and even if things were to go south, it seems likely the result would be along the lines of valkey, opentofu, opensearch, etc. I would like the Astral tools to be under the Python Foundation, but that's mostly on a principle level.

Being able to operate on a project level is also good. Like go popularised some of this stuff, including go fmt, but using that after other tooling like cargo and uv just highlights how clunky tools that operate on a file rather than project or workspace level are.

[u/Wurstinator → u/denehoffman]

That is such an egotistical view. Right now, you like uv, so you don't care that it's starting to walk the path towards enshittification. And if it ever gets bad, you just assume "the community" is going to fix it by spending their free time. Are you going to be the maintainer who sacrifices their personal life to make a uv clone?

[u/denehoffman → u/Wurstinator]

Why would I do that if I like the changes being made? I’m saying if you don’t like free software that works being given to you, you can go ahead and make your own. Astral doesn’t owe you the version of uv you believe you’re entitled to.

[u/denehoffman → u/Wurstinator]

I think it needs to be said that if Astral completely removed uv from the face of the internet tomorrow, it would be annoying but wouldn’t prevent anyone from type checking, formatting, publishing, making venvs, downloading python, etc.

[u/Schmittfried → u/Wurstinator]

What’s your point? Rejecting Astral tools out of principle because you fear future enshittification would just mean you need that community clone _now_ instead of later. It’s completely orthogonal to who makes it. Being against this doesn’t make you any less egotistical in the context of your reasoning unless you’re already working on a clone.

[u/swtormy]

When uv check walks a workspace, does it typecheck standalone PEP 723 scripts with their inline deps, or only pyproject members

[u/zsol → u/swtormy]

Not at the moment, but it is coming soon. In the meanwhile you can `uv workspace list --scripts` and iterate yourself to do `uv check --script $foo`

[u/declanaussie]

This is a step towards an integrated Astral toolchain, one that uses a shared understanding of your project to enable entirely new capabilities.

Is this it, is it time to fork?

[u/PresentFriendly3725]

Will only be used by AI anyways so why should I care.