Devel project for uv — a Python package installer and resolver, written in Rust
Hi, Motivated by Matej's weekly package digest from yesterday, I started working on the python-hatch{,ling} update to version 1.10.0, but hatch has a new dependency on uv - a Rust-based PIP replacement [1]. I have packaged uv in my home project [2] — could not figure out a way to selectively filter out network dependent tests with `%cargo_test` like we can with `%pytest`, so disabled testing for now. I wonder what in your opinions would be the right develproject for this package: d:l:p because it will be used only for python related work or d:l:rust because it is written in rust and d:l:rust maintainers may understand issues pertaining to its maintenance better? [1] https://github.com/astral-sh/uv [2] https://build.opensuse.org/package/show/home:badshah400:Staging/uv Thanks in advance and best wishes, -- Atri
On Mon May 13, 2024 at 7:24 AM CEST, Atri Bhattacharya wrote:
Hi, Motivated by Matej's weekly package digest from yesterday, I started working on the python-hatch{,ling} update to version 1.10.0, but hatch has a new dependency on uv - a Rust-based PIP replacement [1]. I have packaged uv in my home project [2] — could not figure out a way to selectively filter out network dependent tests with `%cargo_test` like we can with `%pytest`, so disabled testing for now.
I have asked our Rust people to join this thread. We really need to develop some strategy (or possibly macros) to deal with Rust extensions in Python packages. Although, thinking about this case, this is probably not that, is it?
I wonder what in your opinions would be the right develproject for this package: d:l:p because it will be used only for python related work or d:l:rust because it is written in rust and d:l:rust maintainers may understand issues pertaining to its maintenance better?
Probably d:l:python. If we are rejecting programs non-related directly to the Python universe, which just happen to be written in Python (e.g., Mercurial), we should probably accept this in reverse. Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Always make new mistakes -- Esther Dyson
Matěj Cepl wrote:
On Mon May 13, 2024 at 7:24 AM CEST, Atri Bhattacharya wrote:
Hi, Motivated by Matej's weekly package digest from yesterday, I started working on the python-hatch{,ling} update to version 1.10.0, but hatch has a new dependency on uv - a Rust-based PIP replacement [1]. I have packaged uv in my home project [2] — could not figure out a way to selectively filter out network dependent tests with `%cargo_test` like we can with `%pytest`, so disabled testing for now. I have asked our Rust people to join this thread. We really need to develop some strategy (or possibly macros) to deal with Rust extensions in Python packages. Although, thinking about this case, this is probably not that, is it?
This is just a standalone pip replacement, albeit written in rust, so not directly related to that, but it is a good time to start planning about Rust-In-Python regardless.
I wonder what in your opinions would be the right develproject for this package: d:l:p because it will be used only for python related work or d:l:rust because it is written in rust and d:l:rust maintainers may understand issues pertaining to its maintenance better? Probably d:l:python. If we are rejecting programs non-related directly to the Python universe, which just happen to be written in Python (e.g., Mercurial), we should probably accept this in reverse.
All right, thanks for the suggestion. I just submitted the rq: https://build.opensuse.org/request/show/1173622. Best wishes, -- Atri
Hi, Am 13.05.24 um 02:53 schrieb Atri Bhattacharya:
Matěj Cepl wrote:
On Mon May 13, 2024 at 7:24 AM CEST, Atri Bhattacharya wrote:
Hi, Motivated by Matej's weekly package digest from yesterday, I started working on the python-hatch{,ling} update to version 1.10.0, but hatch has a new dependency on uv - a Rust-based PIP replacement [1]. I have packaged uv in my home project [2] — could not figure out a way to selectively filter out network dependent tests with `%cargo_test` like we can with `%pytest`, so disabled testing for now. I have asked our Rust people to join this thread. We really need to develop some strategy (or possibly macros) to deal with Rust extensions in Python packages. Although, thinking about this case, this is probably not that, is it? This is just a standalone pip replacement, albeit written in rust, so not directly related to that, but it is a good time to start planning about Rust-In-Python regardless.
Rust-In-Python as of now is usually handled by maturin, which is a fully compliant PEP517 backend. So unless there is a compelling reason to switch from `pip wheel` to `uv pip wheel`, I think we have everything already in place with the `%pyproject_*` macros and the cargo_vendor service. Example: https://build.opensuse.org/package/show/devel:languages:python:jupyter/pytho...
All right, thanks for the suggestion. I just submitted the rq: https://build.opensuse.org/request/show/1173622.
Good work!
Best wishes, -- Atri
- Ben
Ben Greiner wrote:
Hi,
Am 13.05.24 um 02:53 schrieb Atri Bhattacharya:
Matěj Cepl wrote: On Mon May 13, 2024 at 7:24 AM CEST, Atri Bhattacharya wrote: Hi, Motivated by Matej's weekly package digest from yesterday, I started working on the python-hatch{,ling} update to version 1.10.0, but hatch has a new dependency on uv - a Rust-based PIP replacement [1]. I have packaged uv in my home project [2] — could not figure out a way to selectively filter out network dependent tests with `%cargo_test` like we can with `%pytest`, so disabled testing for now. I have asked our Rust people to join this thread. We really need to develop some strategy (or possibly macros) to deal with Rust extensions in Python packages. Although, thinking about this case, this is probably not that, is it? This is just a standalone pip replacement, albeit written in rust, so not directly related to that, but it is a good time to start planning about Rust-In-Python regardless. Rust-In-Python as of now is usually handled by maturin, which is a fully compliant PEP517 backend. So unless there is a compelling reason to switch from `pip wheel` to `uv pip wheel`, I think we have everything already in place with the `%pyproject_*` macros and the cargo_vendor service. Example:
https://build.opensuse.org/package/show/devel:languages:python:jupyter/pytho...
Thanks, Ben, for the example. Will help me in the future.
All right, thanks for the suggestion. I just submitted the rq: https://build.opensuse.org/request/show/1173622. Good work!
Thanks. Unfortunately, my main goal, which was to get hatch 1.10.0 tests working, seems to have failed nonetheless: https://build.opensuse.org/package/show/home:badshah400:branches:devel:langu.... I am unsure if this is directly related to uv or not, and have not been able to investigate in detail owing to sickness for the last ~1 week. Suggestions welcome. Best wishes, -- Atri
participants (3)
-
Atri Bhattacharya -
Ben Greiner -
Matěj Cepl