Is there any reason to still use Rye, now? looks like this release adds all the things I would have missed from Rye, but I don't think I use all of Rye's features
See "Rye and Uv: August Is Harvest Season for Python Packaging"[1]
Uv 0.3 – Unified Python packaging
51–60 of 60 posts
Re: Uv 0.3 – Unified Python packaging
#52The documentation suggests that `uv python list` should be able to see my pyenv Python's as well... but it doesn't appear to?
Seems they need to be on $PATH to get picked up. In Rye there's also a command to "register" a Python install at a specific path.
https://docs.astral.sh/uv/concepts/python-versions/#discover...
https://rye.astral.sh/guide/toolchains/#registering-toolchai...
Re: Uv 0.3 – Unified Python packaging
#53The documentation suggests that `uv python list` should be able to see my pyenv Python's as well... but it doesn't appear to?
Seems they need to be on $PATH to get picked up. In Rye there's also a command to "register" a Python install at a specific path. https://docs.astral.sh/uv/concepts/python-versions/#discover... https://rye.astral.sh/guide/toolchains/#registering-toolchai...
My /.pyenv/shims directory is on the path, but still getting nothing from uv about the pyenv versions specifically.
Re: Uv 0.3 – Unified Python packaging
#54https://xkcd.com/927/
Unfortunate that python dev these days requires dependency manager managers to set up an entire for-purpose python just for each project. As opposed to being able to run on the system python (like every other scripting language). A victim of it's popularity. Now since Uv is in Rust we'll need a dependency manager manager manager for it on any OS that's not rolling to compile since what rustc is changes every 3 months…
Probably will need a K8S management cluster to manage your python project management tools that will of course need another cluster manager for managing the project management tools…
Re: Uv 0.3 – Unified Python packaging
#55Does anyone know if Astral has plans to build an LSP like pyright? There are many projects that try to replicate pyright's functionality, pylyzer comes to mind, but don't have sufficient coverage (e.g. missing Generic support). Having a team like Astral's behind creating a fast and good LSP for Python would be great.
Ruff (the linter/formatter from Astral) has its own LSP right now: https://github.com/astral-sh/ruff-lsp. Although Ruff itself now ships with a language server already integrated, so I have no idea what the plan is long term.
Re: Uv 0.3 – Unified Python packaging
#56To 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 server…
> 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?
Re: Uv 0.3 – Unified Python packaging
#57Earlier quoted context omitted.
Seems they need to be on $PATH to get picked up. In Rye there's also a command to "register" a Python install at a specific path. https://docs.astral.sh/uv/concepts/python-versions/#discover... https://rye.astral.sh/guide/toolchains/#registering-toolchai...
My /.pyenv/shims directory is on the path, but still getting nothing from uv about the pyenv versions specifically.
Write an issue on their GitHub if you don't already see one, they're very responsive
Re: Uv 0.3 – Unified Python packaging
#58To 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 server…
> 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?
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?).
Re: Uv 0.3 – Unified Python packaging
#59Earlier quoted context omitted.
My /.pyenv/shims directory is on the path, but still getting nothing from uv about the pyenv versions specifically.
Write an issue on their GitHub if you don't already see one, they're very responsive
Yep, have done https://github.com/astral-sh/uv/issues/6479
Re: Uv 0.3 – Unified Python packaging
#60I'm happy to see uv is adopted in Pixi, which is a new personal favorite:
https://prefix.dev/blog/uv_in_pixi
Reasons for liking pixi, over e.g. poetry:
- Like poetry, it keeps everything in a project-local definition file and environment
But unlike poetry, it also:
- Can install python itself, even ancient versions
- Can install conda packages
- Is extremely fast