[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 https://github.com/thoth-station/package-releases-job/pull/659#discussion_r975778120 and https://github.com/thoth-station/kebechet/issues/1062

https://github.com/thoth-station/core/issues/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

• [x] #1158
• [ ] Start migrating all our projects to pyproject.toml
  • [ ] https://github.com/thoth-station/core/issues/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