[EPIC] Support for PEP 517 / PEP 566

[VannTen]

Problem statement

As a Kebechet user and Python developer, I would like to use modern (aka
current) Python packaging standards and have Kebechet use them naturally.
Namely:

• pyproject.toml
• PEP 566

High-level Goals

Make use of packaging metadata for operations such as releases.

Proposal description

I need to take more looks at the PEP 517 related stuff before proposing
something. I think we should be able to hook into the build system interface
somehow...

Additional context

Prompted by thoth-station/package-releases-job#659 (comment)
and #1062

thoth-station/core#360 is also relevant because well,
we use kebechet on our packages.

It's conceivable that, should we do that, we might eventually drop other methods, depending on how well PEP 517 adoption in the Python community goes.

Acceptance Criteria

• [3pt] Support pyproject.toml and PEP 566 standards in Kebechet version manager #1158
• Start migrating all our projects to pyproject.toml
  • [3pt] Move away from setuptools and use pyproject.toml instead core#360
  • ? look into automating this process

Package dependency locking
How should a lockfile PEP (665 successor) look like?

• [SPIKE] an adapter for thamos library to support generic lockfile formats and specifically for the new PEP 665 lockfile format.

---

This needs refinement.
/sig user-experience

[VannTen]

Some (open) questions to see what it should mean to "support PEP 517"

• how do we support version updating generically (example : setuptools_scm: version == git tag) ?
• how do handle obtaining the dependencies graph for project using neither Pipfile nor requirements.{in,txt}, without harcoding each format ?
• ...

[Gkrumbach07]

/triage accepted