GNU bug report logs - #58587
[PATCH 00/14] Introducing pyproject-build-system.

Previous Next

Package: guix-patches;

Reported by: Marius Bakke <marius <at> gnu.org>

Date: Mon, 17 Oct 2022 20:07:01 UTC

Severity: normal

Tags: patch

Done: Marius Bakke <marius <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Marius Bakke <marius <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 58587 <at> debbugs.gnu.org, Lars-Dominik Braun <lars <at> 6xq.net>
Subject: [bug#58587] [PATCH 04/14] build-system: Add pyproject-build-system.
Date: Thu, 27 Oct 2022 19:23:18 +0200
[Message part 1 (text/plain, inline)]
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skriver:

> Hello,
>
> Marius Bakke <marius <at> gnu.org> writes:
>
>> From: Lars-Dominik Braun <lars <at> 6xq.net>
>>
>> This is an experimental build system based on python-build-system
>> that implements PEP 517-compliant builds.
>>
>> * guix/build-system/pyproject.scm,
>> guix/build/pyproject-build-system.scm,
>> gnu/packages/aux-files/python/sanity-check-next.py,
>
> I know this file is temporary, but I'd keep the copyright/license
> notices header anyway, less it may be forgotten in the future.

Makes sense; done.

>> gnu/packages/python-commencement.scm: New files.
>> * Makefile.am (MODULES): Register the new build systems.
>> * gnu/local.mk (GNU_SYSTEM_MODULES): Add python-commencement.scm.
>
> Seems this could be merged into gnu/packages/python-build.scm instead of
> creating a new module.

I think you reviewed an old revision; the latest revision adds
python-toolchain straight into python.scm.

We may have to bring back python-commencement.scm for bootstrapping
setuptools and friends at a later core-updates cycle though.

>> +              ;; Prefer pytest
>> +              (if pytest 'pytest #f)
>> +              (if nosetests 'nose #f)
>> +              (if nose2 'nose2 #f)
>> +              ;; But fall back to setup.py, which should work for most
>> +              ;; packages. XXX: would be nice not to depend on setup.py here? fails
>> +              ;; more often than not to find any tests at all. Maybe we can run
>> +              ;; `python -m unittest`?
>> +              (if have-setup-py 'setup.py #f))))
>> +        (format #t "Using ~a~%" use-test-backend)
>> +        (match use-test-backend
>> +          ('pytest
>> +           (apply invoke (cons pytest (or test-flags '("-vv")))))
>> +          ('nose
>> +           (apply invoke (cons nosetests (or test-flags '("-v")))))
>> +          ('nose2
>> +           (apply invoke (cons nose2 (or test-flags '("-v" "--pretty-assert")))))
>
> I think I'd leave the defaults in and document it that way.

By leave, you mean:

  (apply invoke "pytest" "-vv" test-flags)

?

>> +(define* (set-SOURCE-DATE-EPOCH #:rest _)
>
> Perhaps name this set-SOURCE-DATE-EPOCH* to hint that it's not the same
> thing duplicated.

Done; although in the latest revision nothing is duplicated as it
inherits a bunch from python-build-system.

Plans for the immediate core-updates cycle:

* merge sanity-check-next.py into sanity-check.py
* set SOURCE_DATE_EPOCH to ~1980 also in python-build-system
  (and inherit in pyproject-build-system)
* move the compile-bytecode phase into python-build-system
  (currently python-build-system does this during install, hence
   duplication)
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 2 years and 262 days ago.

Previous Next


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