GNU bug report logs - #46848
[PATCHES] [core-updates] PEP 517 python-build-system

Previous Next

Full log

View this message in rfc822 format

From: Marius Bakke <marius <at> gnu.org>
To: Lars-Dominik Braun <lars <at> 6xq.net>, 46848 <at> debbugs.gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: [bug#46848] [PATCHES] [core-updates] PEP 517 python-build-system
Date: Thu, 20 Jan 2022 16:41:09 +0100

[Message part 1 (text/plain, inline)]

Lars-Dominik Braun <lars <at> 6xq.net> skriver:

> I pushed the 3rd version of my new PEP 517-based python-build-system
> into wip-python-pep517. I removed the dependency on python-pypa-build
> for building packages and instead implemented building with a single
> python invokation. This simplifies bootstrapping Python. The 'install
> phase also learned how to create scripts in bin/ from an entry points
> specification.

This is great, thank you.

> Currently 600 of 2212 packages using python-build-system are failing to
> build. That’s alot, but most failures so far were related to testsuites,
> which were not enabled correctly previously because 'check was not
> replaced manually. And some fail because upstream does not separate
> sources and tests and a name clash occurs. This also happens when C
> extensions are build and there does not seem to be a workaround.

Can you elaborate on the name clash issue?

> This number does not include Python 2 packages, which will probably
> break with this new build system. Since Python 2 is EOL anyway I suggest
> to entirely remove Python 2 support before merging this changeset. After
> merging we should upgrade the entire Python ecosystem, because alot of
> packages are already years old.

Unfortunately we need Python 2 for some time still.  It is used to
bootstrap old versions of GHC, Node, and probably other things.

Do you think it is feasible to provide this as a new build system, say
pep517-build-system, during a transitional period?  Then we can a) start
using it right away for the increasing amount of packages that lack a
setup.py; and b) flesh out most bugs before eventually merging it back
(possibly piecemeal) into python-build-system.

I've had a cursory look and it looks good overall.  A few comments:

* Zipping a wheel just to unpack it afterwards is weird, but there seems
  to be no way around it.
* I also think trying "python setup.py test" is unnecessary.
* It would be nice to support the "no tests" case without having to add
  explicit #:tests? everywhere.  Perhaps along the lines of...

  (match use-test-backend
   ('pytest (apply invoke ...))
   [...]
   (_ (match (find-files "." "^test_.*\\.py$")
        (() (format #t "no tests found~%"))
        (_ (apply invoke `("python" "-m" "unittest" ,@test-flags))))))

WDYT?

Great work, and apologies for not chiming in earlier!

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.