build: add build-system via pyproject.toml

[s0h3yl]

Changes

Allows the project to be built w/o the manual installation of cython.

[thequilo]

We initially intentionally didn't add a pyproject.toml file because it used to destroy --user -e installs. But I tested it just now and it seems to work, at least for me.

@boeddeker can you test this on your machine?

We could also push a release to PyPI once you can install it without having to manually install cython before.

[boeddeker]

It looks like the user install might be solved (pypa/pip#7953).
But I remember, that some packages require an older setuptools version, that may not have this fix.
But I forgot which package that was.

I am not sure, if it is worth to add the pyproject.toml:

• The import error has a clear error message and most people know, that they have to type then pip install ... (Those that don't know it, can easily find the solution via a search engine).
• The errors messages that are triggered by pyproject.toml are confusing and usually it is not trivial to solve them.

Although in a scientific environment, Cython should already be installed, so this issue usually happens in CI instances.

[s0h3yl]

@boeddeker I agree, that reading the README.md makes it clear.

Yet, we're using bazel as the build system, which needs PEP-518 compliant packages in order to make them installable - or rather packages that won't need manual steps to be done beforehand.

But I remember, that some packages require an older setuptools version, that may not have this fix.

If you are able to identify that package, you could add version constraints to the given setuptools package.

requires = ["setuptools<68.0.0", "wheel", "Cython"]

In any case, I respect the decision that will be made here. In the event that this PR isn't making it in, we'll use the forked version of this repository and maintain our patch separately.

Thanks in advance! 🙇

[boeddeker]

Yet, we're using bazel as the build system, which needs PEP-518 compliant packages in order to make them installable - or rather packages that won't need manual steps to be done beforehand.

That is an argument, I was waiting for. I didn't know, that software exists, that requires the pyproject.toml.
Until now, it was for me just an ideological change.

If you are able to identify that package, you could add version constraints to the given setuptools package.

We try to delay to breaking old environments, when there is no advantage.
That is the reason, why I wanted to delay the usage of pyproject.toml as long as possible to keep old envs running.

For this package, there is no critical dependency. Our experiment code depends on several packages, and some have difficult version constraints.
Since it is working in Thilos ens, my older envs, and we have a real argument, I think we should merge this PR.

[s0h3yl]

Thank you, @thequilo and @boeddeker! 🙇