Add support for `astral-sh/uv`

[arjxn-py]

Description

uv is a quick Python package installer and resolver, made with Rust. It's meant to work just like pip and pip-tools, but faster.

Motivation

The introduction of the uv tool (https://astral.sh/blog/uv) marks a significant leap in package management efficiency. Offering notable speed improvements over pip, uv demonstrates superior performance across various scenarios. This enhanced speed translates to quicker package installations, contributing to smoother and more efficient workflow experiences.

Possible Implementation

• pyproject.toml
• publish_pypi.yml

Additional context

No response

[agriyakhetarpal]

This would be a great addition even though uv is pretty new and possibly far from production use.

I would suggest waiting on using it with the PyPI publishing workflow (see astral-sh/uv#1663) and rather add it to the PR tests after astral-sh/uv#1646 is resolved from their end (I am indeed following uv's developments pretty closely haha)

[kratman]

Is using pip a bottleneck on any of our tests?

[arjxn-py]

Is using pip a bottleneck on any of our tests?

No that's not the case, but as we have a large dependency tree uv can make significant improvements in workflow speeds, plus example notebooks can also take advantage of the same once we're done experimenting with this new tool and it is stable & production ready.

I anticipate that we'd not just jump on uv considering how fast & efficient it is but would take one step at a time while keeping the infrastructure stable.

[agriyakhetarpal]

I anticipate that we'd not just jump on uv considering how fast & efficient it is but would take one step at a time while keeping the infrastructure stable.

I agree. Let's wait until wntrblm/nox#762 gets merged and receives some feedback by users.

Is using pip a bottleneck on any of our tests?

We don't face a bottleneck as such since pip already receives a lot of the wheels cached in CI (though that hasn't worked all the time for me). What it doesn't do is cache the installation processes, and therefore installations (copying files around with the right permissions, that is) are relatively slower. This is where using uv is of the essence!

[kratman]

I anticipate that we'd not just jump on uv considering how fast & efficient it is but would take one step at a time while keeping the infrastructure stable.

Yeah I would be against switching at an early stage for the tool. Pip is well tested and most users already have it installed. Maybe something to revisit in a year or so

[agriyakhetarpal]

A new release for nox is out which includes a [uv] extra, and it's pretty cool: https://github.com/wntrblm/nox/releases/tag/2024.03.02. Whoever wishes to work on this could also consider adding a nox badge to our README.

[santacodes]

Seems interesting, this could also potentially decrease the build times of docker containers and the project setup times in cookiecutter templates and virtual environments or nox.

pyproject.toml and noxfile.py can be initially worked upon to test this feature and then can be moved to CI/CD (publish_pypi.yml).

I anticipate that we'd not just jump on uv considering how fast & efficient it is but would take one step at a time while keeping the infrastructure stable.

Yeah I would be against switching at an early stage for the tool. Pip is well tested and most users already have it installed. Maybe something to revisit in a year or so

If this issue is not being already worked upon by someone, I would be happy to create a draft for future references.

[kratman]

I still think we should not do this one. I don't see the gain for changing to a new tool when pip is well tested

[kratman]

Just to reiterate, I don't think the pip install is a major bottleneck