Use uv in favour of pip

[Joseph-Edwards]

Before this PR, we used requirements.txt to try and create reproducible environments for our CI to run in. These files are non-standardized, awkward to maintain, and give different behaviour on different systems.

This PR adds uv to our workflow to address these issues. The uv.lock file does the work of the old requirements.txt file, and is automatically generated (by running uv lock) using the information we already specify in pyproject.toml. We now use uv instead of pip in our CI.

I haven't purged requirements.txt and its associated scripts from the project yet, in case there are any users that use them, but I'm happy to do so if we don't think that's an issue

[Joseph-Edwards]

I have some more CI changes that I want to make, but I will do those in a separate PR

[james-d-mitchell]

Thanks @Joseph-Edwards can you also add a bit to the "installing" doc page that indicates how to do it with uv?

[Joseph-Edwards]

It's worth noting that, as a developer, your workflow need not change. If you were using pip install ., to build the package, this will continue to work, as it was not dependent on requirements.txt. I personally use uv pip install ., but that's just because I prefer the UI. As far as I can tell it yields the same result.

[james-d-mitchell]

One thing that I wonder about: would it make sense to retain at least one job using pip in case there's any divergence between pip and uv going forward?

[Joseph-Edwards]

When you say a job using using pip, do you mean:

1. a job that uses pip install . to install libsemigroups_pybind11;
2. a job that installs the dependencies through pin install -r requirements.txt; or
3. both?

I think case 2 (and therefore 3) would be a bit overkill, because that would require maintaining the list of dependencies which this PR aims to remove.

1 would be doable quite easily, but under the hood both pip and uv will be invoking setuptools to build and install the project (I think). As long as both of these tools remain PEP 517 compliant, I don't think their behaviour in this particular instance can deviate too far. That said, that's not a reason to not add a pip job.

What do you think @james-d-mitchell?

[james-d-mitchell]

I was thinking of doing 1, maybe it's not necessary though, my concern arises from the following: we don't use pip in the ci, but we do use pip when building wheels for pypi, and so maybe issues would only show up when building the wheels (at the very end of the process). This is somewhat ameliorated by the fact that we run ci-build wheels in the release candidate's CI. On the other hand, I imagine that debugging ci-build-wheels would be much harder (and more time consuming) than our own CI runners.

So, long way of saying, please leave at least one job using pip (and, say the newest supported version of python).

[Joseph-Edwards]

This PR also changes the pyproject.toml so that cibuildwheel now uses uv. This didn't trigger the running of the wheel jobs unfortunately, but my local tests suggest things are working fine.

In any case, I will add a pip job back to the ci, and also a trivial change to the wheel job so that it runs here.

[Joseph-Edwards]

Going to temporarily close this whilst I debug the CI