zlacker

To me the Astral folks have a lot of credibility because both their ruff linter and formatter have been fantastic. Elevates this kind of announcement from yet another Python packaging thingy to something worth paying attention to.

I like the idea of that single-file Python script with inline dependency info construct, but it's probably going to be a bummer in terms of editor experience. I doubt the typical LSP servers will be aware of dependencies specified in that way and so won't offer autocompletion etc for those libraries.

>>frou_d+(OP)
Good thing we've been investing in our LSP server lately[1]! We're still a ways out from integrating uv into the LSP (and, more generally, providing auto-completions) but it's definitely on our minds.

The script dependency metadata _is_ standardized[2], so other LSP servers could support a good experience here (at least in theory).

[1] The Ruff Language Server: https://astral.sh/blog/ruff-v0.4.5

[2] Inline script metadata: https://peps.python.org/pep-0723/

>>zanie+D3
Do you intend to get to feature parity with pyright for ruff-lsp? I wasn't aware you were aiming to make it a full fledged lsp, despite using it daily.

>>frou_d+(OP)
> I doubt the typical LSP servers will be aware of dependencies specified in that way and so won't offer autocompletion etc for those libraries.

Given this is a recently accepted standard (PEP 723), why would language servers not start to support features based on it?

>>oblvio+Y45
Well it's not that they can't, but it's definitely work because it's a departure from the traditional model.

Consider an editor feature, e.g. goto-definition. When working in a normal Python environment (global or virtual) the code of your dependencies actually exists on the filesystem. With one of these scripts with inline dependency information, that dependency code perhaps doesn't exist on the filesystem at all, and possibly won't ever until after the script has been run in its special way (e.g. with a `pipx run` shebang?).