mbox series

[bug#58587,00/14] Introducing pyproject-build-system.

Message ID 20221017200624.4076-1-marius@gnu.org
Headers show
Series Introducing pyproject-build-system. | expand

Message

Marius Bakke Oct. 17, 2022, 8:06 p.m. UTC 
This is an adaptation of Lars' work in wip-python-pep517 for 'master'.

I've implemented it as a separate build system so we can do a slow
transition, starting at the leafs.

Changes from the original branch:

* Renamed to pyproject-build-system.
* It inherits some code from python-build-system.
* Python 2 and <3.7 support removed.
* A (temporary) sanity-check-next.py file is introduced.
* A new (hidden) 'python-sans-pip' variable is introduced.
* The 'python-toolchain' package includes pip, wheel, setuptools, and
  pypa-build.

The build system logic is unchanged from Lars' branch.

I've converted a handful packages that were doing PEP 517 style builds
to the new build system with great success.  It should help a lot with
packaging "modern" Python packages.

Please try it for new packages, even those using setup.py, and don't be
afraid to report problems!

I plan to eventually merge it with python-build-system instead of
keeping it separate.  Thoughts?

Note: documentation is missing.  Will work on that next.

Lars-Dominik Braun (3):
  gnu: python-setuptools: Move to python-build.
  gnu: pypy: Move to separate module.
  build-system: Add pyproject-build-system.

Marius Bakke (11):
  gnu: python-pip: Move to (gnu packages python-build).
  gnu: python-autopage: Use pyproject-build-system.
  gnu: flair: Switch to pyproject-build-system.
  gnu: python-pydyf: Use pyproject-build-system.
  gnu: weasyprint: Use pyproject-build-system.
  gnu: python-glyphslib: Use pyproject-build-system.
  gnu: python-statmake: Use pyproject-build-system.
  gnu: python-ufolib2: Use pyproject-build-system.
  gnu: python-mypy-protobuf: Switch to pyproject-build-system.
  gnu: python-tempora: Switch to pyproject-build-system.
  gnu: python-pygmsh: Use pyproject-build-system.

 Makefile.am                                   |   2 +
 gnu/local.mk                                  |   2 +
 .../aux-files/python/sanity-check-next.py     |  98 ++++
 gnu/packages/bioinformatics.scm               |  23 +-
 gnu/packages/chemistry.scm                    |   1 +
 gnu/packages/fontutils.scm                    |  91 +---
 gnu/packages/messaging.scm                    |   1 +
 gnu/packages/pdf.scm                          |  40 +-
 gnu/packages/protobuf.scm                     |  15 +-
 gnu/packages/pypy.scm                         | 273 +++++++++++
 gnu/packages/python-build.scm                 |  61 +++
 gnu/packages/python-commencement.scm          |  64 +++
 gnu/packages/python-xyz.scm                   | 110 +----
 gnu/packages/python.scm                       | 180 +------
 gnu/packages/sequoia.scm                      |   2 +-
 gnu/packages/simulation.scm                   |  20 +-
 guix/build-system/pyproject.scm               | 148 ++++++
 guix/build/pyproject-build-system.scm         | 460 ++++++++++++++++++
 tests/lint.scm                                |   2 +-
 19 files changed, 1164 insertions(+), 429 deletions(-)
 create mode 100644 gnu/packages/aux-files/python/sanity-check-next.py
 create mode 100644 gnu/packages/pypy.scm
 create mode 100644 gnu/packages/python-commencement.scm
 create mode 100644 guix/build-system/pyproject.scm
 create mode 100644 guix/build/pyproject-build-system.scm

Comments

Simon Tournier Oct. 18, 2022, 9:33 a.m. UTC | #1 
Hi Marius,

On Mon, 17 Oct 2022 at 22:06, Marius Bakke <marius@gnu.org> wrote:

> This is an adaptation of Lars' work in wip-python-pep517 for 'master'.

Cool!


> I've implemented it as a separate build system so we can do a slow
> transition, starting at the leafs.

[...]

> I plan to eventually merge it with python-build-system instead of
> keeping it separate.  Thoughts?

I would suggest to have a clear plan about this transition strategy. :-)
I mean, if we go to two separated Python build-systems and then merge
them, we have to write down the various steps; otherwise it could be
quickly a mess.

For example,

 1. advertise about this new Python build-system
 2. recommend only this new
 3. only include package using this new
 4. convert from old to new
 5. remove old / rename old to new

or whatever else.  My concern is to have two build systems to maintain
on the long term.

Once something lands to master and the API, it is then hard to modify.
Therefore, it appears to me better to draw beforehand the large lines of
this transition plan.

Cheers,
simon