pyproject.toml: add initial file

[gctucker]

Add an initial pyproject.toml file to be able to build and install the
api Python package.

Thanks to Nikolay Yurin for finding the bug about the license file:
https://github.com/pypa/pip/issues/12251

This project uses a standard license so it's better to just rely on
the LGPL-2.1-or-later SPDX indentifier instead of providing the path
to the whole license file.

Development dependencies have been omitted and all the required
dependencies have a fixed version in order to build reproducible
Docker images for production deployment.  Some follow-up changes can
be made to have a better way to handle dependencies for development.

Fixes: #326

[gctucker]

Thanks @yurinnick for finding the bug about the license file. I've now updated #329 accordingly to not install dependencies from requirements.txt but only rely on pyproject.toml.

[gctucker]

Tested OK with the early access deployment.

[yurinnick]

You can add optional dependencies as well:

[project.optional-dependencies]
dev = [
  "pycodestyle ~= 2.8.0",
  "pylint ~= 2.12.2"
]
test = [
  "fakeredis ~= 1.7.0",
  "pytest ~= 6.2.5",
  "pytest-asyncio ~= 0.16.0",
  "pytest-dependency ~= 0.5.1",
  "pytest-mock ~= 3.6.1",
  "pytest-order ~= 1.0.1",
  "httpx ~= 0.23.3",
]

And install it with pip install -e .[dev,test]

[gctucker]

You can add optional dependencies as well:

[project.optional-dependencies]
dev = [
  "pycodestyle ~= 2.8.0",
  "pylint ~= 2.12.2"
]
test = [
  "fakeredis ~= 1.7.0",
  "pytest ~= 6.2.5",
  "pytest-asyncio ~= 0.16.0",
  "pytest-dependency ~= 0.5.1",
  "pytest-mock ~= 3.6.1",
  "pytest-order ~= 1.0.1",
  "httpx ~= 0.23.3",
]

And install it with pip install -e .[dev,test]

Yes, I know. But as per the commit message:

Development dependencies have been omitted and all the required
dependencies have a fixed version in order to build reproducible
Docker images for production deployment. Some follow-up changes can
be made to have a better way to handle dependencies for development.

I deliberately left the optional ones out as it's not required for the production deployment. Also, typically for development and in the project settings in general we should probably not pin down every package version, but it's necessary in order to reproduce the Docker images in production. So this is just a first step, and the development use-case will need to be addressed as a follow-up.

[yurinnick]

Just to be on the same page, these dependencies won't go into production image, unless dev and/or test groups are explicitly specified during installation.

[gctucker]

Yes, I know that too. But I don't think we should just add them like that and keep the required dependencies pinned down as it's not convenient for development.

[yurinnick]

Got it! So you want to keep to unpinned and flexible for development, but pinned to production Docker image build.

[gctucker]

Yes I think that's the ideal case. That's why you'll see most of the pyproject files have a minimal version set but not a pinned one for each depdenency. I think the typical way to do this in the past has been to list the dependencies in setup.py without versions, but have requirements.txt with pinned versions. I'm not sure if we can do something nicer with pyproject now, like override the fixed version in a dev section.

Alright I think we'll merge this and you can rebase your PR and address this kind if issues there if you want.