Build PyPI wheels

[joasode]

We need a build setup based on our pyproject.toml file. Since cotainr is a pure python package, we should only need to build a single wheel and sdist source distribution for all OS'es and architectures.

The setup must:

• Use setuptools as a build backend.
• Use uv build as build frontend.

[joasode]

The current major build backends for building wheels are listed here. We should decide on which one is most appropriate for the cotainr project. In PR #57 Hatchling is suggested. This branch docker-build-ci suggest SetupTools (>= 61.0).

uv currently only have a build frontend, however the Astral team is currently deliberating whether building a uv build backend would be their strategic decision.

Further down the line we could consider building one various linux variations using https://github.com/pypa/manylinux if the need arose.

Regarding the decision on what build backend system we should use, it seems like for a pure python package like cotainr, there should not really be any difference. The key difference I see is if we want to use some specific workflow automation from the build frontend. As I see it, the only automation in #57 is the [tool.hatch.version] table, which seems seems to be implented in setuptools [tool.setuptools.dynamic] table. So I would suggest the conservative option of following PyPA and use Setuptools (>= 61.0) as build backend and pip (>= 19.0) or build as build frontend. Then we also have a natural choice for the CI in issue #94 ciwheelbuild. At least until we can do it all in uv ;)

@Chroxvi @TheBlackKoala @juliusroeder any thoughts?

[Chroxvi]

I agree with your assessment @joasode, and I don't have a strong opinion on the choice of backend/frontend. I don't think we need to care too much about the manylinux standards as cotainr is pure Python package with no compiled extensions.

In my work in the pip_package branch, I used flit as it is a very simple tool for pure Python packages. It had a few short comings, though:

1. Installation of different dependency sets (docs, tests, etc.) gets a little clumsy.
2. It is not easy to include extra files in the wheel, e.g. if you wanted to include the doc folder in the wheel.

As for setuptools, I have found that difficult to use and maintain in the past, but that was 10 years ago before the we had all the nice pyproject.toml and frontend/backend standards....

To minimize the number of dependencies, I would like to try with uv as frontend instead of build since we plan to use uv for installing dependencies anyway.