[PATCHES] [core-updates] PEP 517 python-build-system

  • Done
  • quality assurance status badge
Details
4 participants
  • Hartmut Goebel
  • Lars-Dominik Braun
  • Marius Bakke
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Lars-Dominik Braun
Severity
normal
L
L
Lars-Dominik Braun wrote on 1 Mar 2021 14:43
(address . guix-patches@gnu.org)
YDzveovrLETvBlkE@noor.fritz.box
Hi everyone,

the attached patches switch python-build-system to a PEP 517-based build
system using python-pypa-build.

As discussed previously Python is currently in the process of opening up
for build systems other than setuptools using the API specified in PEP
517. python-pypa-build is a simple tool for building packages using that
new API. It supports setup.py-based builds as a fallback, if no
pyproject.toml is present.

One downside is that this tool is not self-contained and has a few
dependencies. Thus first I bootstrap setuptools using itself (possible
because it bundles all of its own dependencies), then build
python-pypa-build’s dependencies using setuptools (which is fortunately
still possible) and then combine everything into a
python-toolchain(-for-build), which is then used by the build-process.

I can successfully build packages like python-pypa-build and
python-pytest and python-pep517-bootstrap. The latter is using flit as
its build backend. But other packages currently fail because I removed
some arguments.

Cheers,
Lars
From 7ace01faef72f3a48b18fe241fe0524445a154fb Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Fri, 19 Feb 2021 17:22:35 +0100
Subject: [PATCH 01/12] build/python: Handle missing setuptools in
sanity-check.py

Just skip testing if required dependencies (setuptools) are not
available.

* gnu/packages/aux-files/python/sanity-check.py: Handle ImportError.
---
gnu/packages/aux-files/python/sanity-check.py | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

Toggle diff (21 lines)
diff --git a/gnu/packages/aux-files/python/sanity-check.py b/gnu/packages/aux-files/python/sanity-check.py
index 83b6d583ca..240155cecc 100644
--- a/gnu/packages/aux-files/python/sanity-check.py
+++ b/gnu/packages/aux-files/python/sanity-check.py
@@ -19,9 +19,13 @@
from __future__ import print_function # Python 2 support.
import importlib
-import pkg_resources
import sys
import traceback
+try:
+ import pkg_resources
+except ImportError:
+ print('Warning: Skipping, because python-setuptools are not available.')
+ sys.exit(0)
try:
from importlib.machinery import PathFinder
--
2.26.2
From 66033f14455456d465a3c9f5a2d1f4961cd3b989 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 12:50:42 +0100
Subject: [PATCH 02/12] gnu: python-pypa-build: Update to 0.3.0.

* gnu/packages/python-build.scm (python-pypa-build): Update to 0.3.0.
---
gnu/packages/python-build.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

Toggle diff (22 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index 140629ca43..92dbda314f 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -118,13 +118,13 @@ Language (TOML) configuration files.")
(define-public python-pypa-build
(package
(name "python-pypa-build")
- (version "0.1.0")
+ (version "0.3.0")
(source (origin
(method url-fetch)
(uri (pypi-uri "build" version))
(sha256
(base32
- "1d6m21lijwm04g50nwgsgj7x3vhblzw7jv05ah8psqgzk20bbch8"))))
+ "1pazq66c35whrqd5b0zcydjvy2rmghi8riljkd67q3bpiln5pf8f"))))
(build-system python-build-system)
(arguments
`(#:tests? #f ;to tests in the PyPI release
--
2.26.2
From 00ef998413dc0fe6605653ae16f65d6377c2ec77 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:02:15 +0100
Subject: [PATCH 03/12] gnu: python-wheel: Install entrypoint scripts

* gnu/packages/python-build.scm (pythont-wheel) [arguments]: Add phase
'patch-enable-entrypoints.
---
gnu/packages/python-build.scm | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)

Toggle diff (28 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index 92dbda314f..232e24f470 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -47,10 +47,17 @@
"0ii6f34rvpjg3nmw4bc2h7fhdsy38y1h93hghncfs5akfrldmj8h"))))
(build-system python-build-system)
(arguments
- ;; FIXME: The test suite runs "python setup.py bdist_wheel", which in turn
- ;; fails to find the newly-built bdist_wheel library, even though it is
- ;; available on PYTHONPATH. What search path is consulted by setup.py?
- '(#:tests? #f))
+ `(#:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'patch-enable-entrypoints
+ (lambda _
+ ;; python-wheel tells setuptools to not install entry point scripts
+ ;; by default. Stop doing that, so wheels built contain all data
+ ;; required.
+ (substitute* "wheel/bdist_wheel.py"
+ (("(install_scripts\\.no_ep = )True" all assignment)
+ (string-append assignment "False")))
+ #t)))))
(home-page "https://bitbucket.org/pypa/wheel/")
(synopsis "Format for built Python packages")
(description
--
2.26.2
From 61313d8ddba30772e2587e3e16ca30d1565d3c7e Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:05:51 +0100
Subject: [PATCH 04/12] gnu: python-setuptools: Bootstrap using itself

* gnu/packages/python-xyz.scm (python-setuptools) [arguments]: Add phase
setting GUIX_PYTHONPATH to source directory.
---
gnu/packages/python-xyz.scm | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

Toggle diff (26 lines)
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index f8afa13f33..79d01f700a 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -1144,7 +1144,18 @@ other machines, such as over the network.")
;; FIXME: Tests require pytest, which itself relies on setuptools.
;; One could bootstrap with an internal untested setuptools.
(arguments
- `(#:tests? #f))
+ `(#:tests? #f
+ #:python ,python-wrapper
+ #:phases (modify-phases %standard-phases
+ ;; Use this setuptools’ sources to bootstrap themselves.
+ (add-before 'build 'set-PYTHONPATH
+ (lambda _
+ (format #t "current working dir ~s~%" (getcwd))
+ (setenv "GUIX_PYTHONPATH"
+ (string-append ".:" (getenv "GUIX_PYTHONPATH")))
+ #t)))))
+ ;; Not required when not building a wheel
+ ;(propagated-inputs `(("python-wheel" ,python-wheel)))
(home-page "https://pypi.org/project/setuptools/")
(synopsis
"Library designed to facilitate packaging Python projects")
--
2.26.2
From 14b70dea3d21684e7fdb66dd072031cef3214b07 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:17:10 +0100
Subject: [PATCH 06/12] gnu: Add python-pytoml.

* gnu/packages/python-build.scm (python-pytoml): Add new variable.
---
gnu/packages/python-build.scm | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

Toggle diff (27 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index 232e24f470..a6a310177c 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -173,3 +173,20 @@ implementation developed for Poetry. This project is intended to be
a light weight, fully compliant, self-contained package allowing PEP 517
compatible build front-ends to build Poetry managed projects.")
(license license:expat)))
+
+(define-public python-pytoml
+ (package
+ (name "python-pytoml")
+ (version "0.1.21")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "pytoml" version))
+ (sha256
+ (base32
+ "1rv1byiw82k7mj6aprcrqi2vdabs801y97xhfnrz7kxds34ggv4f"))))
+ (build-system python-build-system)
+ (home-page "https://github.com/avakar/pytoml")
+ (synopsis "A parser for TOML-0.4.0")
+ (description "A parser for TOML-0.4.0")
+ (license license:expat)))
--
2.26.2
From e8b1f40157b3d884bb2fc3e3d10bbfbd469c67b9 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:18:17 +0100
Subject: [PATCH 07/12] gnu: Add python-flit-core.

* gnu/packages/python-build.scm (python-flit-core): New variable.
---
gnu/packages/python-build.scm | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)

Toggle diff (37 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index a6a310177c..f767704a78 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -190,3 +190,30 @@ compatible build front-ends to build Poetry managed projects.")
(synopsis "A parser for TOML-0.4.0")
(description "A parser for TOML-0.4.0")
(license license:expat)))
+
+(define-public python-flit-core
+ (package
+ (name "python-flit-core")
+ (version "3.0.0")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "flit_core" version))
+ (sha256
+ (base32
+ "0bbw84r33gwi0xyp7m8dzp2dzpjs4harj3l5wrbxkmp2awh0ard4"))))
+ (build-system python-build-system)
+ (arguments
+ `(;; No tests.
+ #:tests? #f))
+ (propagated-inputs
+ `(("python-pytoml" ,python-pytoml)))
+ (home-page "https://github.com/takluyver/flit")
+ (synopsis
+ "Simplified packaging of Python modules, distribution-building parts")
+ (description
+ "Flit is a simple way to put Python packages and modules on PyPI. It
+tries to require less thought about packaging and help you avoid common
+mistakes. Distribution-building parts of Flit.")
+ (license license:bsd-3)))
+
--
2.26.2
From 316c25f310cad4dd8f0cb73a914a4776b1b1375c Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:20:48 +0100
Subject: [PATCH 08/12] gnu: python-pep517-bootstrap: Build using flit-core.

* gnu/packages/python-build.scm (python-pep517-bootstrap) [arguments]:
Relax dependency on flit-core version.
[native-inputs]: Add flit-core.
---
gnu/packages/python-build.scm | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

Toggle diff (29 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index f767704a78..f74a3ee49e 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -110,10 +110,21 @@ Language (TOML) configuration files.")
"0zqidxah03qpnp6zkg3zd1kmd5f79hhdsfmlc0cldaniy80qddxf"))))
(build-system python-build-system)
(arguments
- `(#:tests? #f)) ;to avoid circular dependencies
+ `(#:tests? #f ; To avoid circular dependencies.
+ #:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'relax-dependency
+ (lambda _
+ (substitute* "pyproject.toml"
+ (("flit_core >=2,<3")
+ "flit_core >=2,<4"))
+ #t)))))
(propagated-inputs
`(("python-toml" ,python-toml)
("python-wheel" ,python-wheel)))
+ (native-inputs
+ `(;; Build system.
+ ("python-flit-core" ,python-flit-core)))
(home-page "https://github.com/pypa/pep517")
(synopsis "Wrappers to build Python packages using PEP 517 hooks")
(description
--
2.26.2
From c8898a6a282daaa2cceabfac96e417f7b09e8d5f Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:23:53 +0100
Subject: [PATCH 09/12] gnu: python-iniconfig: Add missing build input.

* gnu/packages/python-xyz.scm (python-iniconfig) [native-inputs] Add
setuptools-scm.
---
gnu/packages/python-xyz.scm | 1 +
1 file changed, 1 insertion(+)

Toggle diff (14 lines)
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 79d01f700a..d598a380a9 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -15704,6 +15704,7 @@ in other versions.")
(base32
"0ckzngs3scaa1mcfmsi1w40a1l8cxxnncscrxzjjwjyisx8z0fmw"))))
(build-system python-build-system)
+ (native-inputs `(("python-setuptools-scm" ,python-setuptools-scm)))
(home-page "https://github.com/RonnyPfannschmidt/iniconfig")
(synopsis "Simple INI-file parser")
(description "The @code{iniconfig} package provides a small and simple
--
2.26.2
From 8f5c9398ac1a6ac1871d5cf8a1efbe6a70ed4a1b Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Mon, 1 Mar 2021 14:16:07 +0100
Subject: [PATCH 10/12] gnu: Add python-u-msgpack.

* gnu/packages/python-xyz.scm (python-u-msgpack): New variable.

The redundant -python postfix from the original package name has been
removed.
---
gnu/packages/python-xyz.scm | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)

Toggle diff (34 lines)
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index d598a380a9..ab3c6d301e 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -23659,3 +23659,27 @@ Application Programming Interface based on the Open Inventor 2.1 API.")
Crayons automatically wraps a given string in the foreground color and
restores the original state after the string is printed.")
(license license:expat)))
+
+(define-public python-u-msgpack
+ (package
+ (name "python-u-msgpack")
+ (version "2.7.1")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "u-msgpack-python" version))
+ (sha256
+ (base32
+ "0lcmlr7gc4dydpxn6l5bdcq40c3ghf8mv1sjqyj72wdpr8rx9rxp"))))
+ (build-system python-build-system)
+ (home-page
+ "https://github.com/vsergeev/u-msgpack-python")
+ (synopsis
+ "Portable, lightweight MessagePack serializer and deserializer")
+ (description
+ "A portable, lightweight MessagePack serializer and deserializer written
+in pure Python. u-msgpack-python is fully compliant with the latest MessagePack
+specification. In particular, it supports the new binary, UTF-8 string,
+application-defined ext, and timestamp types.")
+ (license license:expat)))
+
--
2.26.2
From 39eef77658f400ccfceb65b6fcd3f4996ae90807 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Mon, 1 Mar 2021 14:20:03 +0100
Subject: [PATCH 11/12] gnu: Add python-pytest-expect.

* gnu/packages/python-check.scm (python-pytest-expect): New variable.
---
gnu/packages/python-check.scm | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)

Toggle diff (38 lines)
diff --git a/gnu/packages/python-check.scm b/gnu/packages/python-check.scm
index 9849b16685..4139f3cdde 100644
--- a/gnu/packages/python-check.scm
+++ b/gnu/packages/python-check.scm
@@ -1251,3 +1251,31 @@ help in debugging failures and optimizing the scheduler to improve speed.")
(description "A pytest plugin for Sanic. It helps you to test your
code asynchronously.")
(license license:expat)))
+
+(define-public python-pytest-expect
+ (package
+ (name "python-pytest-expect")
+ (version "1.1.0")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "pytest-expect" version))
+ (sha256
+ (base32
+ "0iyq3zd1g5ffaz2wv6mskjfn84sfbyh0j209glcrh1s50hkldd1n"))))
+ (build-system python-build-system)
+ (arguments `(#:tests? #f)) ; no tests via pypi
+ (propagated-inputs
+ `(("python-pytest" ,python-pytest) ; package declares this dependency
+ ("python-u-msgpack" ,python-u-msgpack)))
+ (home-page
+ "https://github.com/gsnedders/pytest-expect")
+ (synopsis
+ "Py.test plugin to store test expectations and mark tests based on them")
+ (description
+ "A py.test plugin that stores test expectations by saving the set of
+failing tests, allowing them to be marked as xfail when running them in future.
+The tests expectations are stored such that they can be distributed alongside
+the tests.")
+ (license license:expat)))
+
--
2.26.2
From 4ed7eba12c80dd33f20626ddb81abc34dd667ab3 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Mon, 1 Mar 2021 14:23:07 +0100
Subject: [PATCH 12/12] gnu: python-html5lib: Fix tests with pytest 6.

* gnu/packages/python-web.scm (python-html5lib) [source]: Add upstream
patch.
[native-inputs]: Add test dependencies.
[arguments]: Remove unsupported #:test-target.
---
gnu/packages/python-web.scm | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)

Toggle diff (37 lines)
diff --git a/gnu/packages/python-web.scm b/gnu/packages/python-web.scm
index 947c200253..c484d7ba36 100644
--- a/gnu/packages/python-web.scm
+++ b/gnu/packages/python-web.scm
@@ -1020,13 +1020,27 @@ storage.")
(uri (pypi-uri "html5lib" version))
(sha256
(base32
- "0vqlhk0hgbsfkh7ybmby93xhlx8dq6pr5blf356ka3z2c41b9rdj"))))
+ "0vqlhk0hgbsfkh7ybmby93xhlx8dq6pr5blf356ka3z2c41b9rdj"))
+ (patches
+ (list
+ ;; Adds Pytest 6 support.
+ (origin
+ (method url-fetch)
+ (uri (string-append
+ "https://github.com/html5lib/"
+ "html5lib-python/commit/"
+ "2c19b9899ab3a3e8bd0ca35e5d78544334204169.patch"))
+ (file-name "python-html5lib-support-pytest6.patch")
+ (sha256
+ (base32
+ "0jg2ry0439q8n7j1mf4p2hdq54i704pq9scv4wwa2pp3cwvb6dvg")))))))
(build-system python-build-system)
(propagated-inputs
`(("python-six" ,python-six)
("python-webencodings" ,python-webencodings)))
- (arguments
- `(#:test-target "check"))
+ (native-inputs
+ `(("python-pytest" ,python-pytest)
+ ("python-pytest-expect" ,python-pytest-expect)))
(home-page
"https://github.com/html5lib/html5lib-python")
(synopsis
--
2.26.2
L
L
Lars-Dominik Braun wrote on 15 May 2021 11:31
(address . 46848@debbugs.gnu.org)
YJ+VD+Xcb7tCU6FF@noor.fritz.box
Hi,

I rebased my changes on top of the current core-updates HEAD.

Cheers,
Lars
From 9d9c417fba869913366a12c89b7309ecc402777d Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Fri, 19 Feb 2021 17:22:35 +0100
Subject: [PATCH 01/14] build/python: Handle missing setuptools in
sanity-check.py

Just skip testing if required dependencies (setuptools) are not
available.

* gnu/packages/aux-files/python/sanity-check.py: Handle ImportError.
---
gnu/packages/aux-files/python/sanity-check.py | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

Toggle diff (21 lines)
diff --git a/gnu/packages/aux-files/python/sanity-check.py b/gnu/packages/aux-files/python/sanity-check.py
index 83b6d583ca..240155cecc 100644
--- a/gnu/packages/aux-files/python/sanity-check.py
+++ b/gnu/packages/aux-files/python/sanity-check.py
@@ -19,9 +19,13 @@
from __future__ import print_function # Python 2 support.
import importlib
-import pkg_resources
import sys
import traceback
+try:
+ import pkg_resources
+except ImportError:
+ print('Warning: Skipping, because python-setuptools are not available.')
+ sys.exit(0)
try:
from importlib.machinery import PathFinder
--
2.26.3
From 5cdfe3f6de27be54eeaa5c507a62319c3783ff1a Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 12:50:42 +0100
Subject: [PATCH 02/14] gnu: python-pypa-build: Update to 0.3.0.

* gnu/packages/python-build.scm (python-pypa-build): Update to 0.3.0.
---
gnu/packages/python-build.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

Toggle diff (22 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index 59ee91aa9c..25e2f1e60f 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -136,13 +136,13 @@ Language (TOML) configuration files.")
(define-public python-pypa-build
(package
(name "python-pypa-build")
- (version "0.1.0")
+ (version "0.3.0")
(source (origin
(method url-fetch)
(uri (pypi-uri "build" version))
(sha256
(base32
- "1d6m21lijwm04g50nwgsgj7x3vhblzw7jv05ah8psqgzk20bbch8"))))
+ "1pazq66c35whrqd5b0zcydjvy2rmghi8riljkd67q3bpiln5pf8f"))))
(build-system python-build-system)
(arguments
`(#:tests? #f ;to tests in the PyPI release
--
2.26.3
From 9516a9e734009f7e38acb37a51f704de9e6198ef Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:02:15 +0100
Subject: [PATCH 03/14] gnu: python-wheel: Install entrypoint scripts

* gnu/packages/python-build.scm (pythont-wheel) [arguments]: Add phase
'patch-enable-entrypoints.
---
gnu/packages/python-build.scm | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)

Toggle diff (28 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index 25e2f1e60f..bbd273e5de 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -49,10 +49,17 @@
"0ii6f34rvpjg3nmw4bc2h7fhdsy38y1h93hghncfs5akfrldmj8h"))))
(build-system python-build-system)
(arguments
- ;; FIXME: The test suite runs "python setup.py bdist_wheel", which in turn
- ;; fails to find the newly-built bdist_wheel library, even though it is
- ;; available on PYTHONPATH. What search path is consulted by setup.py?
- '(#:tests? #f))
+ `(#:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'patch-enable-entrypoints
+ (lambda _
+ ;; python-wheel tells setuptools to not install entry point scripts
+ ;; by default. Stop doing that, so wheels built contain all data
+ ;; required.
+ (substitute* "wheel/bdist_wheel.py"
+ (("(install_scripts\\.no_ep = )True" all assignment)
+ (string-append assignment "False")))
+ #t)))))
(home-page "https://bitbucket.org/pypa/wheel/")
(synopsis "Format for built Python packages")
(description
--
2.26.3
From 19349bf56a88feb5ebc0d24c4f3324e776b2f5ff Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:05:51 +0100
Subject: [PATCH 04/14] gnu: python-setuptools: Bootstrap using itself

* gnu/packages/python-xyz.scm (python-setuptools) [arguments]: Add phase
setting GUIX_PYTHONPATH to source directory.
---
gnu/packages/python-xyz.scm | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

Toggle diff (26 lines)
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index eebb44b9dc..8f472dea42 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -1390,7 +1390,18 @@ other machines, such as over the network.")
;; FIXME: Tests require pytest, which itself relies on setuptools.
;; One could bootstrap with an internal untested setuptools.
(arguments
- `(#:tests? #f))
+ `(#:tests? #f
+ #:python ,python-wrapper
+ #:phases (modify-phases %standard-phases
+ ;; Use this setuptools’ sources to bootstrap themselves.
+ (add-before 'build 'set-PYTHONPATH
+ (lambda _
+ (format #t "current working dir ~s~%" (getcwd))
+ (setenv "GUIX_PYTHONPATH"
+ (string-append ".:" (getenv "GUIX_PYTHONPATH")))
+ #t)))))
+ ;; Not required when not building a wheel
+ ;(propagated-inputs `(("python-wheel" ,python-wheel)))
(home-page "https://pypi.org/project/setuptools/")
(synopsis
"Library designed to facilitate packaging Python projects")
--
2.26.3
From 881a8e817a1fe21a39bcfdc3e5be2d2ac7760cb9 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:17:10 +0100
Subject: [PATCH 06/14] gnu: Add python-pytoml.

* gnu/packages/python-build.scm (python-pytoml): Add new variable.
---
gnu/packages/python-build.scm | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

Toggle diff (27 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index bbd273e5de..238fc8b3a5 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -191,3 +191,20 @@ implementation developed for Poetry. This project is intended to be
a light weight, fully compliant, self-contained package allowing PEP 517
compatible build front-ends to build Poetry managed projects.")
(license license:expat)))
+
+(define-public python-pytoml
+ (package
+ (name "python-pytoml")
+ (version "0.1.21")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "pytoml" version))
+ (sha256
+ (base32
+ "1rv1byiw82k7mj6aprcrqi2vdabs801y97xhfnrz7kxds34ggv4f"))))
+ (build-system python-build-system)
+ (home-page "https://github.com/avakar/pytoml")
+ (synopsis "A parser for TOML-0.4.0")
+ (description "A parser for TOML-0.4.0")
+ (license license:expat)))
--
2.26.3
From 545fa78c3a42f5cc22ccc9ea70e0ff1f9bcebe5c Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:18:17 +0100
Subject: [PATCH 07/14] gnu: Add python-flit-core.

* gnu/packages/python-build.scm (python-flit-core): New variable.
---
gnu/packages/python-build.scm | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)

Toggle diff (37 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index 238fc8b3a5..8940e6490b 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -208,3 +208,30 @@ compatible build front-ends to build Poetry managed projects.")
(synopsis "A parser for TOML-0.4.0")
(description "A parser for TOML-0.4.0")
(license license:expat)))
+
+(define-public python-flit-core
+ (package
+ (name "python-flit-core")
+ (version "3.0.0")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "flit_core" version))
+ (sha256
+ (base32
+ "0bbw84r33gwi0xyp7m8dzp2dzpjs4harj3l5wrbxkmp2awh0ard4"))))
+ (build-system python-build-system)
+ (arguments
+ `(;; No tests.
+ #:tests? #f))
+ (propagated-inputs
+ `(("python-pytoml" ,python-pytoml)))
+ (home-page "https://github.com/takluyver/flit")
+ (synopsis
+ "Simplified packaging of Python modules, distribution-building parts")
+ (description
+ "Flit is a simple way to put Python packages and modules on PyPI. It
+tries to require less thought about packaging and help you avoid common
+mistakes. Distribution-building parts of Flit.")
+ (license license:bsd-3)))
+
--
2.26.3
From 4ffe19ccc9b6d077c811cfbdd715d10a79730e8f Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:20:48 +0100
Subject: [PATCH 08/14] gnu: python-pep517-bootstrap: Build using flit-core.

* gnu/packages/python-build.scm (python-pep517-bootstrap) [arguments]:
Relax dependency on flit-core version.
[native-inputs]: Add flit-core.
---
gnu/packages/python-build.scm | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

Toggle diff (29 lines)
diff --git a/gnu/packages/python-build.scm b/gnu/packages/python-build.scm
index 8940e6490b..c53d49c287 100644
--- a/gnu/packages/python-build.scm
+++ b/gnu/packages/python-build.scm
@@ -128,10 +128,21 @@ Language (TOML) configuration files.")
"0zqidxah03qpnp6zkg3zd1kmd5f79hhdsfmlc0cldaniy80qddxf"))))
(build-system python-build-system)
(arguments
- `(#:tests? #f)) ;to avoid circular dependencies
+ `(#:tests? #f ; To avoid circular dependencies.
+ #:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'relax-dependency
+ (lambda _
+ (substitute* "pyproject.toml"
+ (("flit_core >=2,<3")
+ "flit_core >=2,<4"))
+ #t)))))
(propagated-inputs
`(("python-toml" ,python-toml)
("python-wheel" ,python-wheel)))
+ (native-inputs
+ `(;; Build system.
+ ("python-flit-core" ,python-flit-core)))
(home-page "https://github.com/pypa/pep517")
(synopsis "Wrappers to build Python packages using PEP 517 hooks")
(description
--
2.26.3
From f1eea04f204dc0fef64675ac2605f42535aa0815 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Sun, 28 Feb 2021 13:23:53 +0100
Subject: [PATCH 09/14] gnu: python-iniconfig: Add missing build input.

* gnu/packages/python-xyz.scm (python-iniconfig) [native-inputs] Add
setuptools-scm.
---
gnu/packages/python-xyz.scm | 1 +
1 file changed, 1 insertion(+)

Toggle diff (14 lines)
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 8f472dea42..47466d31f0 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -17110,6 +17110,7 @@ in other versions.")
(base32
"0ckzngs3scaa1mcfmsi1w40a1l8cxxnncscrxzjjwjyisx8z0fmw"))))
(build-system python-build-system)
+ (native-inputs `(("python-setuptools-scm" ,python-setuptools-scm)))
(home-page "https://github.com/RonnyPfannschmidt/iniconfig")
(synopsis "Simple INI-file parser")
(description "The @code{iniconfig} package provides a small and simple
--
2.26.3
From 271997517b2b03aec44e8b158c911412caccf7bf Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Mon, 1 Mar 2021 14:16:07 +0100
Subject: [PATCH 10/14] gnu: Add python-u-msgpack.

* gnu/packages/python-xyz.scm (python-u-msgpack): New variable.

The redundant -python postfix from the original package name has been
removed.
---
gnu/packages/python-xyz.scm | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)

Toggle diff (34 lines)
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 47466d31f0..fdc9bd85b7 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -25575,3 +25575,27 @@ is the cythonized version of @code{fractions.Fraction}.")
"@code{pathvalidate} is a Python library to sanitize/validate strings
representing paths or filenames.")
(license license:expat)))
+
+(define-public python-u-msgpack
+ (package
+ (name "python-u-msgpack")
+ (version "2.7.1")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "u-msgpack-python" version))
+ (sha256
+ (base32
+ "0lcmlr7gc4dydpxn6l5bdcq40c3ghf8mv1sjqyj72wdpr8rx9rxp"))))
+ (build-system python-build-system)
+ (home-page
+ "https://github.com/vsergeev/u-msgpack-python")
+ (synopsis
+ "Portable, lightweight MessagePack serializer and deserializer")
+ (description
+ "A portable, lightweight MessagePack serializer and deserializer written
+in pure Python. u-msgpack-python is fully compliant with the latest MessagePack
+specification. In particular, it supports the new binary, UTF-8 string,
+application-defined ext, and timestamp types.")
+ (license license:expat)))
+
--
2.26.3
From 77f5e2e445e01c3ce7b1c9484ca27ba86b9d5def Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Mon, 1 Mar 2021 14:20:03 +0100
Subject: [PATCH 11/14] gnu: Add python-pytest-expect.

* gnu/packages/python-check.scm (python-pytest-expect): New variable.
---
gnu/packages/python-check.scm | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)

Toggle diff (38 lines)
diff --git a/gnu/packages/python-check.scm b/gnu/packages/python-check.scm
index ff29f5d7ce..80fb5f704a 100644
--- a/gnu/packages/python-check.scm
+++ b/gnu/packages/python-check.scm
@@ -1515,3 +1515,31 @@ allows one to create a set of tests using @emph{pairwise combinations} method,
reducing a number of combinations of variables into a lesser set that covers
most situations.")
(license license:expat)))
+
+(define-public python-pytest-expect
+ (package
+ (name "python-pytest-expect")
+ (version "1.1.0")
+ (source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "pytest-expect" version))
+ (sha256
+ (base32
+ "0iyq3zd1g5ffaz2wv6mskjfn84sfbyh0j209glcrh1s50hkldd1n"))))
+ (build-system python-build-system)
+ (arguments `(#:tests? #f)) ; no tests via pypi
+ (propagated-inputs
+ `(("python-pytest" ,python-pytest) ; package declares this dependency
+ ("python-u-msgpack" ,python-u-msgpack)))
+ (home-page
+ "https://github.com/gsnedders/pytest-expect")
+ (synopsis
+ "Py.test plugin to store test expectations and mark tests based on them")
+ (description
+ "A py.test plugin that stores test expectations by saving the set of
+failing tests, allowing them to be marked as xfail when running them in future.
+The tests expectations are stored such that they can be distributed alongside
+the tests.")
+ (license license:expat)))
+
--
2.26.3
From 2e2eb3c05f285f3bfc4c990309584eb98503cd91 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Mon, 1 Mar 2021 14:23:07 +0100
Subject: [PATCH 12/14] gnu: python-html5lib: Fix tests with pytest 6.

* gnu/packages/python-web.scm (python-html5lib) [source]: Add upstream
patch.
[native-inputs]: Add test dependencies.
[arguments]: Remove unsupported #:test-target.
---
gnu/packages/python-web.scm | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)

Toggle diff (38 lines)
diff --git a/gnu/packages/python-web.scm b/gnu/packages/python-web.scm
index 8b31368424..8ab783bbb3 100644
--- a/gnu/packages/python-web.scm
+++ b/gnu/packages/python-web.scm
@@ -1079,7 +1079,20 @@ storage.")
(uri (pypi-uri "html5lib" version))
(sha256
(base32
- "0vqlhk0hgbsfkh7ybmby93xhlx8dq6pr5blf356ka3z2c41b9rdj"))))
+ "0vqlhk0hgbsfkh7ybmby93xhlx8dq6pr5blf356ka3z2c41b9rdj"))
+ (patches
+ (list
+ ;; Adds Pytest 6 support.
+ (origin
+ (method url-fetch)
+ (uri (string-append
+ "https://github.com/html5lib/"
+ "html5lib-python/commit/"
+ "2c19b9899ab3a3e8bd0ca35e5d78544334204169.patch"))
+ (file-name "python-html5lib-support-pytest6.patch")
+ (sha256
+ (base32
+ "0jg2ry0439q8n7j1mf4p2hdq54i704pq9scv4wwa2pp3cwvb6dvg")))))))
(build-system python-build-system)
(propagated-inputs
`(("python-six" ,python-six)
@@ -1088,6 +1101,9 @@ storage.")
("python-chardet" ,python-chardet)))
(arguments
`(#:test-target "check"))
+ (native-inputs
+ `(("python-pytest" ,python-pytest)
+ ("python-pytest-expect" ,python-pytest-expect)))
(home-page
"https://github.com/html5lib/html5lib-python")
(synopsis
--
2.26.3
From 312ee407e5d878da99098753ba24641c2c468451 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Mon, 1 Mar 2021 17:18:50 +0100
Subject: [PATCH 13/14] gnu: python-libxml2: Fix build.

* gnu/packages/xml.scm (python-libxml2) [#:phases]: Replace setuptools
and do not exit at the end of setup.py.
---
gnu/packages/xml.scm | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

Toggle diff (18 lines)
diff --git a/gnu/packages/xml.scm b/gnu/packages/xml.scm
index 9accd08a7e..9d93d21e27 100644
--- a/gnu/packages/xml.scm
+++ b/gnu/packages/xml.scm
@@ -370,7 +370,10 @@ It uses libxml2 to access the XML files.")
(format #f "ROOT = r'~a'" libxml2))
;; For 'iconv.h'.
(("/opt/include")
- (string-append glibc "/include"))))
+ (string-append glibc "/include"))
+ (("distutils\\.core") "setuptools")
+ ;; python-pypa-build does not like it if setup.py exits.
+ (("sys\\.exit\\(0\\)") "")))
#t)))))
(inputs `(("libxml2" ,libxml2)))
(synopsis "Python bindings for the libxml2 library")))
--
2.26.3
From ec72099a90b0fc7f6538f578ab3e28411391dacb Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Mon, 1 Mar 2021 17:21:35 +0100
Subject: [PATCH 14/14] gnu: scons: Remove obsolete argument.

* gnu/packages/python-xyz.scm (scons) [arguments]: Remove #:use-setuptools?
argument.
---
gnu/packages/python-xyz.scm | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

Toggle diff (16 lines)
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index fdc9bd85b7..a61451f8ea 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -2641,8 +2641,7 @@ and is not compatible with JSON.")
"1xy8jrwz87y589ihcld4hv7wn122sjbz914xn8h50ww77wbhk8hn"))))
(build-system python-build-system)
(arguments
- `(#:use-setuptools? #f ; still relies on distutils
- #:tests? #f ; no 'python setup.py test' command
+ `(#:tests? #f ; no 'python setup.py test' command
#:phases
(modify-phases %standard-phases
(add-before 'build 'bootstrap
--
2.26.3
L
L
Lars-Dominik Braun wrote on 6 Jun 2021 21:44
Re: Questions regarding Python packaging
(name . Tanguy LE CARROUR)(address . tanguy@bioneland.org)
YL0loaz6X4+Kp69t@noor.fritz.box
Hi Tanguy,

(cross-posting this to the issue itself too)

Toggle quote (3 lines)
> Sorry if I'm (very) late, but apprently this hasn't made it to master
> yet, so… What the status? Do you still need a willing-but-maybe-not-qualified
> person to review or discuss your patch?
the patch set works, I can build many Python packages, although some
require changes. Still, multiple things need to be done before merging
is possible imo:

1) Validate the general idea of using pypa-build is viable and
sustainable in the long run – ideally through review by someone else
than me. We can’t touch python-build-system every week to solve
structural issues, so it needs to be bullet-proof.
2) Figure out how to run testing code. Currently python-build-system
just picks pytest, if available – not sure this is the best option we
have. How do we deal with other test systems? How do we pass options?
3) Determine the fate of Python 2, which is probably broken through this
patch set. Shall we remove it entirely? Is it worth to keep support?
4) Iron out minor details like including pip in the python package or
create a new python-toolchain package? What do we include in that
meta-package? pip? virtualenv? …?
5) Fix my awkward Scheme code, especially regarding unpacking of the
built wheels. Should we be using Python’s unzip module or can be
assumed unzip is available in the build environment? (Should we add
it?)

I’m by no means a Python packaging expert, so any help would be
appreciated, even if it’s just a question or thumbs-up/thumbs-down on my
ideas.

Cheers,
Lars
H
H
Hartmut Goebel wrote on 22 Jun 2021 09:00
(name . Lars-Dominik Braun)(address . lars@6xq.net)
520a5492-6467-bbfc-3252-f17a5cc5d16f@crazy-compilers.com
Hi Lars,

sorry for being late for commenting on this (the time I can spend on
guix is rather limited atm).

Here are some general remarks on this patch-set (in order of appearance):

*

Not installing pip by default might break some user's environments.
Anyhow, since using pip in guix is not such a good idea anyway, this
should be okay.

*

"use-setuptools" is gone. There are still about 10 packages with
"#:use-setuptools #f" - which means they are (expected to be)
incompatible with setuptools for some reason. You might want to
check whether these packages actually still can't be packages with
setuptools.

*

setuptools-shim has been removed. I don't think this is a good idea,
since this peace of code enforces packages to be actually build with
setuptools instead of old distutils. This code is still in current
pip, so I assume it is still required.

(This shim ensures setuptools is used, even if setup.py only imports
distutils. And setuptools is required for some options like
""--single-version-externally-managed" - as the comment for the shim
says.)

*

set-SOURCE-DATE-EPOCH: Please keep the verbose rational. It's much
more helpful than the new one-line comment.

*

set-SOURCE-DATE-EPOCH: This implementation makes the code depend on
wheel and wheel being used for installation.

*

Why has rename-pth-file been removed? Are you sure .pth-files are
never created anymore nowerdays?

*

python-hashbang: Isn't this done already by the normal
"patch-shebangs" phase after install in  gnu-build-system? (BTW:
these are called *she*bangs).

*

I suggest to have phase compile-bytecode still honor older versions
of python


Toggle quote (5 lines)
> 1) Validate the general idea of using pypa-build is viable and
> sustainable in the long run – ideally through review by someone else
> than me. We can’t touch python-build-system every week to solve
> structural issues, so it needs to be bullet-proof.

pypa bulld is where the PyPA is pushing towards. Anyhow, as of today, as
far as I can see, adoption is low.

Toggle quote (4 lines)
> 2) Figure out how to run testing code. Currently python-build-system
> just picks pytest, if available – not sure this is the best option we
> have. How do we deal with other test systems? How do we pass options?

AFAIK fhere is no standard way for running tests in python. pytest seems
to be the most modern test-system. Anyhow packages still use nose or tox
(which again might run pytest or nose, with parameters fetched from
tox.ini). So I'm afraid, there is no general rule.

Did the PyPA publish some recommendations or PEP on this?

Toggle quote (4 lines)
> 4) Iron out minor details like including pip in the python package or
> create a new python-toolchain package? What do we include in that
> meta-package? pip? virtualenv? …?

As I Python developer I nowerdays would expect pip and venv (which is
part of the std-lib - but not the virualenv, which is a separate module)
to be availalbe when installing "python". Anyhow I could live with pip
being a separate package.

"python-toolchain" sounds oversized for me. Would this include the
C-compiler, too (which one? maybe I want to build cross). I'd rather not
have such a package.

Toggle quote (4 lines)
> 5) Fix my awkward Scheme code, especially regarding unpacking of the
> built wheels. Should we be using Python’s unzip module or can be
> assumed unzip is available in the build environment? (Should we add
> it?)
The gnu-build-system already provides the "unzip" binary (used in phase
"unpack"). So we could simply use this. Otherwise I recommend using the
Python zip module, as this is what is used for creating the zip-archives
:-)

--
Regards
Hartmut Goebel

| Hartmut Goebel | h.goebel@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Attachment: file
L
L
Lars-Dominik Braun wrote on 28 Jun 2021 13:59
(name . Hartmut Goebel)(address . h.goebel@crazy-compilers.com)
YNm5oxRelWX1LyWM@noor.fritz.box
Hi Hartmut,

Toggle quote (2 lines)
> sorry for being late for commenting on this (the time I can spend on
> guix is rather limited atm).
no problem, same thing on my side.

Toggle quote (5 lines)
> *
>
> Not installing pip by default might break some user's environments.
> Anyhow, since using pip in guix is not such a good idea anyway, this
> should be okay.
True. We could rename python→python-minimal-interpreteronly (or similar;
given that python-minimal already exists) and python-toolchain→python to
work around that.

Toggle quote (7 lines)
> *
>
> "use-setuptools" is gone. There are still about 10 packages with
> "#:use-setuptools #f" - which means they are (expected to be)
> incompatible with setuptools for some reason. You might want to
> check whether these packages actually still can't be packages with
> setuptools.
Yeah, I’ve seen those, but the number was too small to bother for now.
I’ll have a look later.

Toggle quote (11 lines)
> *
>
> setuptools-shim has been removed. I don't think this is a good idea,
> since this peace of code enforces packages to be actually build with
> setuptools instead of old distutils. This code is still in current
> pip, so I assume it is still required.
>
> (This shim ensures setuptools is used, even if setup.py only imports
> distutils. And setuptools is required for some options like
> ""--single-version-externally-managed" - as the comment for the shim
> says.)
Is this relevant though? I doubt many packages are still importing
distutils and the few that do can be patched.

Toggle quote (4 lines)
> *
>
> set-SOURCE-DATE-EPOCH: Please keep the verbose rational. It's much
> more helpful than the new one-line comment.
You mean the one from the now-removed ensure-no-mtimes-pre-1980? Sure.

Toggle quote (4 lines)
> *
>
> set-SOURCE-DATE-EPOCH: This implementation makes the code depend on
> wheel and wheel being used for installation.
Technically it depends on the wheel builder understanding
SOURCE_DATE_EPOCH (not necessarily python-wheel). I’d say that’s
acceptable and it’d be preferable to fix build systems not respecting
this variable imo.


Toggle quote (4 lines)
> *
>
> Why has rename-pth-file been removed? Are you sure .pth-files are
> never created anymore nowerdays?
Given that easy-install has been deprecated I think it’s safe to remove
this phase and flag any packages creating this easy-install.pth as
broken. (There are, however, legitimate packages creating files like
ruamel.yaml-0.15.83-py3.8-nspkg.pth.)

Toggle quote (5 lines)
> *
>
> python-hashbang: Isn't this done already by the normal
> "patch-shebangs" phase after install in  gnu-build-system? (BTW:
> these are called *she*bangs).
Afaik the function patch-shebang expects a leading slash and thus it
does not replace this “special” shebang (see
Spread, point 3).

Toggle quote (4 lines)
> *
>
> I suggest to have phase compile-bytecode still honor older versions
> of python
I’m not sure what you mean. compileall is also part of Python 2.

Toggle quote (2 lines)
> pypa bulld is where the PyPA is pushing towards. Anyhow, as of today, as
> far as I can see, adoption is low.
Of pypa build? That is true.

Toggle quote (6 lines)
> AFAIK fhere is no standard way for running tests in python. pytest seems
> to be the most modern test-system. Anyhow packages still use nose or tox
> (which again might run pytest or nose, with parameters fetched from
> tox.ini). So I'm afraid, there is no general rule.
>
> Did the PyPA publish some recommendations or PEP on this?
I’m not aware of any accepted PEP’s. There is a discussion about the
removal of `python setup.py test`:
And a proposal for pyproject.toml going nowhere:

Toggle quote (4 lines)
> As I Python developer I nowerdays would expect pip and venv (which is
> part of the std-lib - but not the virualenv, which is a separate module)
> to be availalbe when installing "python". Anyhow I could live with pip
> being a separate package.
If we keep setuptools/pip bundled, we don’t have to do any of this
pypa-build dance. We could also modernize python-build-system around
`pip install` and just be done with it. (I don’t have a proof-of-concept
for that yet.)

Toggle quote (3 lines)
> "python-toolchain" sounds oversized for me. Would this include the
> C-compiler, too (which one? maybe I want to build cross). I'd rather not
> have such a package.
See suggestion above wrt renaming.

Toggle quote (4 lines)
> The gnu-build-system already provides the "unzip" binary (used in phase
> "unpack"). So we could simply use this. Otherwise I recommend using the
> Python zip module, as this is what is used for creating the zip-archives
> :-)
I’m using Python’s zipfile module already.

Cheers,
Lars
H
H
Hartmut Goebel wrote on 28 Jun 2021 22:37
(name . Lars-Dominik Braun)(address . lars@6xq.net)
681eb450-0185-a465-3ed1-8446e8ad0974@crazy-compilers.com
Hi Lars-Dominik,

Am 28.06.21 um 13:59 schrieb Lars-Dominik Braun:*
Toggle quote (7 lines)
>> Not installing pip by default might break some user's environments.
>> Anyhow, since using pip in guix is not such a good idea anyway, this
>> should be okay.
> True. We could rename python→python-minimal-interpreteronly (or similar;
> given that python-minimal already exists) and python-toolchain→python to
> work around that.

What should be the use of having a package without pip? Anything else
than saving a few KB?


Toggle quote (4 lines)
>> [setuptools-shim has been removed]
> Is this relevant though? I doubt many packages are still importing
> distutils and the few that do can be patched.

Was I wrote: This code is still in pip, so I assume it is still relevant.

I don't think patching is a good idea. It requires effort (implementing,
reviewing), which can be saved by keeping exisiting and tested code.


Toggle quote (7 lines)
>> set-SOURCE-DATE-EPOCH: This implementation makes the code depend on
>> wheel and wheel being used for installation.
> Technically it depends on the wheel builder understanding
> SOURCE_DATE_EPOCH (not necessarily python-wheel). I’d say that’s
> acceptable and it’d be preferable to fix build systems not respecting
> this variable imo.

For this case please change the comment not not referring to wheel in
this way. More something like "we expect the builder to support
SOURCE_DATE_EPOCH, like wheel does"

Anyhow, *m not actually convinced that we should throw away the old
code. I can imagine in the next cuple of years quite some new
build-systems to arrive, most of which will most probably not support
SOURCE_DATE_EPOCH in the beginning, and thus making package's life harder.


Toggle quote (8 lines)
>
>> Why has rename-pth-file been removed? Are you sure .pth-files are
>> never created anymore nowerdays?
> Given that easy-install has been deprecated I think it’s safe to remove
> this phase and flag any packages creating this easy-install.pth as
> broken. (There are, however, legitimate packages creating files like
> ruamel.yaml-0.15.83-py3.8-nspkg.pth.)

What exaclty do you mean with "flag as broken"? Will anybody (you? ;-)
verify *all* current packages to not be "broken" prior to merging this
change?

Anyhow, again, I'm not convinced we should remove this phase now.
.pth-file are deprecated only, but still supported. By removing this
phase we might create conflict cased we can not foresee. And I would
keep it even if one analyzes none of the current packages is "broken" -
just do be on the save side fpr avoiding user trouble. (These issues
will show up at the user, and are hard to track down, since noone will
think about .pth files)


Toggle quote (9 lines)
>
>> python-hashbang: Isn't this done already by the normal
>> "patch-shebangs" phase after install in  gnu-build-system? (BTW:
>> these are called *she*bangs).
> Afaik the function patch-shebang expects a leading slash and thus it
> does not replace this “special” shebang (see
> https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl;
> Spread, point 3).

IC. Please add a comment to make this clear (e.g. "handle shebang of
scripts generated by wheel missing leading slash")

Toggle quote (6 lines)
>> *
>>
>> I suggest to have phase compile-bytecode still honor older versions
>> of python
> I’m not sure what you mean. compileall is also part of Python 2.

The old code did not compile the source for Python <3.7. Please see the
comment of the old code for rational.


Toggle quote (9 lines)
>> As I Python developer I nowerdays would expect pip and venv (which is
>> part of the std-lib - but not the virualenv, which is a separate module)
>> to be availalbe when installing "python". Anyhow I could live with pip
>> being a separate package.
> If we keep setuptools/pip bundled, we don’t have to do any of this
> pypa-build dance. We could also modernize python-build-system around
> `pip install` and just be done with it. (I don’t have a proof-of-concept
> for that yet.)

AFAIK this might not be true if other build systems not using setuptools
at all might show up. And isn't this the main reason for all your work?


Toggle quote (6 lines)
>
>> The gnu-build-system already provides the "unzip" binary (used in phase
>> "unpack"). So we could simply use this. Otherwise I recommend using the
>> Python zip module, as this is what is used for creating the zip-archives
>> :-)
> I’m using Python’s zipfile module already.
Fine, so you can safely remove the respective comment ;-)

--
Regards
Hartmut Goebel

| Hartmut Goebel | h.goebel@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
L
L
Lars-Dominik Braun wrote on 29 Jun 2021 09:20
(name . Hartmut Goebel)(address . h.goebel@crazy-compilers.com)
YNrJt2tbUNieWY3S@noor.fritz.box
Hi Hartmut,

Toggle quote (2 lines)
> What should be the use of having a package without pip? Anything else
> than saving a few KB?
saving some space and unvendoring components that we also have separate
packages for. (As I understand it, ensurepip, which installs both pip and
setuptools, is merely a convenience tool if you install Python from
source yourself – not for distributions.)

Toggle quote (2 lines)
> AFAIK this might not be true if other build systems not using setuptools
> at all might show up. And isn't this the main reason for all your work?
No, try

cd pep517
pip wheel --use-pep517 -v .

which has no setup.py and uses flit instead. pip can build it, because
it supports PEP 517-based builds. As I said, if we decide to keep it
bundled with our python package, there’s no good reason to choose
pypa-build.

Cheers,
Lars
L
L
Lars-Dominik Braun wrote on 6 Jul 2021 14:16
(name . Hartmut Goebel)(address . h.goebel@crazy-compilers.com)
YORJg/svC9lKUI6+@noor.fritz.box
Hi again,

Toggle quote (10 lines)
> No, try
>
> git clone https://github.com/pypa/pep517.git
> cd pep517
> pip wheel --use-pep517 -v .
>
> which has no setup.py and uses flit instead. pip can build it, because
> it supports PEP 517-based builds. As I said, if we decide to keep it
> bundled with our python package, there’s no good reason to choose
> pypa-build.
I now have a proof of concept for a pip-based python-build-system, see
1st patch. The changeset is quite small, but it does not handle testing
at all right now.

Note that alot of setuptools-based packages lack a dependency on
python-wheel (2nd patch; pardon the whitespace errors), which is
required when using pyproject.toml (and also declared there, but our
Python importer cannot read that file yet). But – as expected – that’s
really the only issue I’ve encountered while rebuilding alot of Python
packages so far.

Cheers,
Lars
H
H
Hartmut Goebel wrote on 7 Jul 2021 17:01
(name . Lars-Dominik Braun)(address . lars@6xq.net)
716d2bce-bc89-2442-a02a-3bcbcbe19219@crazy-compilers.com
Am 29.06.21 um 09:20 schrieb Lars-Dominik Braun:
Toggle quote (4 lines)
>> AFAIK this might not be true if other build systems not using setuptools
>> at all might show up. And isn't this the main reason for all your work?
> No, try

Sorry, I've been inprecise on this:

There might still be quite some packages out there importing plain, old
distutils (and not setuptools) in their setup.py. These are what I meant
with "other build systems not using setuptools". For these setup.py to
understand the options we (and pip) need for installation, "import
distutils" has to be hacked to actually become "import setuptools" -
which is what setuptools-shim does

--
Regards
Hartmut Goebel

| Hartmut Goebel | h.goebel@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Attachment: file
L
L
Lars-Dominik Braun wrote on 25 Aug 2021 09:56
(address . 46848@debbugs.gnu.org)
YSX3tdHUA0h636fm@noor.fritz.box
Hi,

Toggle quote (6 lines)
> > What should be the use of having a package without pip? Anything else
> > than saving a few KB?
> saving some space and unvendoring components that we also have separate
> packages for. (As I understand it, ensurepip, which installs both pip and
> setuptools, is merely a convenience tool if you install Python from
> source yourself – not for distributions.)
there is another crucial one: Collisions. Right now our python-pip and
python-setuptools packages are rather useless, because they collide with
the Python-bundled one. I’m trying to update Jupyter currently and
python-jupyter-packaging depends on a newer setuptools (v46ish) than our
python package provides (v41). Adding python-setuptools (v52) to the
propagated inputs (yes, it’s a runtime dependency), would be the natural
solution, but the resulting setuptools package in the build environment
for packages depending on python-jupyter-packaging is a mix between v42
and v52 and does not work.

Cheers,
Lars
L
L
Lars-Dominik Braun wrote on 13 Dec 2021 21:10
Re: [bug#46848] [PATCHES] [core-updates] PEP 517 python-build-system
(address . 46848@debbugs.gnu.org)
YbeomE4Q02bPiPM+@noor.fritz.box
Hi,

I’m working on version 3 of this patchset, removing the dependency
on python-pypa-build, which simplifies bootstrapping. A rough version
is available at


Cheers,
Lars
L
L
Lars-Dominik Braun wrote on 5 Jan 2022 15:51
(address . 46848@debbugs.gnu.org)(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
YdWwcWM5I+zJW8tU@noor.fritz.box
Hi everyone,

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.

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.

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.

Cheers,
Lars

PS: Maxim: This is your ping for a review (via #52269). Thanks :)
M
M
Marius Bakke wrote on 20 Jan 2022 16:41
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
877daubeju.fsf@gnu.org
Lars-Dominik Braun <lars@6xq.net> skriver:

Toggle quote (7 lines)
> 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.

Toggle quote (7 lines)
> 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?

Toggle quote (6 lines)
> 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!
-----BEGIN PGP SIGNATURE-----

iIUEARYKAC0WIQRNTknu3zbaMQ2ddzTocYulkRQQdwUCYemClQ8cbWFyaXVzQGdu
dS5vcmcACgkQ6HGLpZEUEHekigD/fOVOE7lCfRW0OuNWk9gGTLOZOQpqO8+MmiJI
CaWULd4A/3mf5Srz1hublc4NlZMb5NanVzduIrpl7YlBn1XN2NMJ
=JNtc
-----END PGP SIGNATURE-----

L
L
Lars-Dominik Braun wrote on 20 Jan 2022 19:43
(name . Marius Bakke)(address . marius@gnu.org)
YemtTA5nsPjVXu5L@noor.fritz.box
Hi Marius,

Toggle quote (1 lines)
> Can you elaborate on the name clash issue?
the problem seems to be that most packages do not put the source code
into a subdirectory in the sdist. I.e. package foobar will have a foobar/
directory, instead of src/foobar. Thus Python tries to load the module
foobar.barbaz from that directory, instead of the store. Thus it’ll
also look there for C extensions and fail. I don’t know why it does
that, even when *not* using `python -m` – according to the documentation
it should not. If anyone has any pointers I’d like to have a look again.

Toggle quote (2 lines)
> Unfortunately we need Python 2 for some time still. It is used to
> bootstrap old versions of GHC, Node, and probably other things.
But as far as I see these specific examples do not use
python-build-system. Only if some package using `#:python python-2` is
required during bootstrapping, then we’d need a way to support Python
2, right?

Toggle quote (5 lines)
> 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.
Actually, I think that’s a good idea. I tried, but I cannot fix all
packages broken by this change on my own, so smoothing the transition
could help and – as you said – we could catch bugs early on.

I could prepare a patch, if there is interest in this path.

Toggle quote (2 lines)
> * Zipping a wheel just to unpack it afterwards is weird, but there seems
> to be no way around it.
Indeed, that’s how PEP 517 works, which always builds a wheel
(i.e. ZIP file).

Toggle quote (1 lines)
> * I also think trying "python setup.py test" is unnecessary.
It still works quite often, although its usefulness will decrease in
the future I guess. Another problem I see is that this command will not
fail if there are no tests.

Toggle quote (2 lines)
> * It would be nice to support the "no tests" case without having to add
> explicit #:tests? everywhere. Perhaps along the lines of...
My idea was to force packagers to make and explain this decision
explicitly. If you don’t run tests, you have to add `#:tests? #f`
and leave a comment why they are disabled. I do see this could become
a hassle with packages that simply don’t have any tests. But my hope
is that it increases package quality.
Toggle quote (1 lines)
> (_ (apply invoke `("python" "-m" "unittest" ,@test-flags))))))
If I remember correctly I tried this and it did not work for some
reason. I’ll have a look again.

Cheers,
Lars
M
M
Marius Bakke wrote on 20 Jan 2022 21:43
(name . Lars-Dominik Braun)(address . lars@6xq.net)
874k5yb0jd.fsf@gnu.org
Lars-Dominik Braun <lars@6xq.net> skriver:

Toggle quote (11 lines)
> Hi Marius,
>
>> Can you elaborate on the name clash issue?
> the problem seems to be that most packages do not put the source code
> into a subdirectory in the sdist. I.e. package foobar will have a foobar/
> directory, instead of src/foobar. Thus Python tries to load the module
> foobar.barbaz from that directory, instead of the store. Thus it’ll
> also look there for C extensions and fail. I don’t know why it does
> that, even when *not* using `python -m` – according to the documentation
> it should not. If anyone has any pointers I’d like to have a look again.

Perhaps it could be worked around by building in a separate directory,
i.e. ./build/lib, like setuptools does? And ensure that the original
source directory does not end up on {,GUIX_}PYTHONPATH.

(I don't really understand the problem, just throwing ideas around.)

Toggle quote (7 lines)
>> Unfortunately we need Python 2 for some time still. It is used to
>> bootstrap old versions of GHC, Node, and probably other things.
> But as far as I see these specific examples do not use
> python-build-system. Only if some package using `#:python python-2` is
> required during bootstrapping, then we’d need a way to support Python
> 2, right?

Right. If we don't need any Python 2 modules it should be fine to
remove support from the build system.

Toggle quote (11 lines)
>> 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.
> Actually, I think that’s a good idea. I tried, but I cannot fix all
> packages broken by this change on my own, so smoothing the transition
> could help and – as you said – we could catch bugs early on.
>
> I could prepare a patch, if there is interest in this path.

It would lower the bar significantly for testing and contributing, so I
would appreciate it. :-)

Toggle quote (13 lines)
>> * I also think trying "python setup.py test" is unnecessary.
> It still works quite often, although its usefulness will decrease in
> the future I guess. Another problem I see is that this command will not
> fail if there are no tests.
>
>> * It would be nice to support the "no tests" case without having to add
>> explicit #:tests? everywhere. Perhaps along the lines of...
> My idea was to force packagers to make and explain this decision
> explicitly. If you don’t run tests, you have to add `#:tests? #f`
> and leave a comment why they are disabled. I do see this could become
> a hassle with packages that simply don’t have any tests. But my hope
> is that it increases package quality.

My main concern is end-user experience when they just want to get some
random library working on their local channel. But it's arguably
something that can be solved on the importer level and not a strong
opinion.

Thinking about importers, perhaps they could start emitting git origins
when possible, as there is a trend to strip tests before uploading to
PyPI.

Toggle quote (4 lines)
>> (_ (apply invoke `("python" "-m" "unittest" ,@test-flags))))))
> If I remember correctly I tried this and it did not work for some
> reason. I’ll have a look again.

Eh, it should be (apply invoke "python" "-m" "unittest" test-flags), but
you probably got that. :-P

Thanks!
-----BEGIN PGP SIGNATURE-----

iIUEARYKAC0WIQRNTknu3zbaMQ2ddzTocYulkRQQdwUCYenJhg8cbWFyaXVzQGdu
dS5vcmcACgkQ6HGLpZEUEHeGuwD9H2BY3O9ueLy3SB08wMJF/fov3rf5Yv8pnOR5
U1ljuasA/340yEq0yCLyQD4/iqk1v7G4JOwTP5DtgHDLiC+GTi0J
=3u8K
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 23 Jan 2022 06:29
Re: bug#46848: [PATCHES] [core-updates] PEP 517 python-build-system
(name . Lars-Dominik Braun)(address . lars@6xq.net)(address . 46848@debbugs.gnu.org)
87ee4z6mv5.fsf@gmail.com
Hi Lars,

Here's a review of patches 1 to 6.

Lars-Dominik Braun <lars@6xq.net> writes:

Toggle quote (3 lines)
> the attached patches switch python-build-system to a PEP 517-based build
> system using python-pypa-build.

Neat! Thank you for working on this!

Toggle quote (41 lines)
> One downside is that this tool is not self-contained and has a few
> dependencies. Thus first I bootstrap setuptools using itself (possible
> because it bundles all of its own dependencies), then build
> python-pypa-build’s dependencies using setuptools (which is fortunately
> still possible) and then combine everything into a
> python-toolchain(-for-build), which is then used by the build-process.
>
> I can successfully build packages like python-pypa-build and
> python-pytest and python-pep517-bootstrap. The latter is using flit as
> its build backend. But other packages currently fail because I removed
> some arguments.
> Lars
>
>
>
>
>>From 61313d8ddba30772e2587e3e16ca30d1565d3c7e Mon Sep 17 00:00:00 2001
> From: Lars-Dominik Braun <lars@6xq.net>
> Date: Sun, 28 Feb 2021 13:05:51 +0100
> Subject: [PATCH 04/12] gnu: python-setuptools: Bootstrap using itself
>
> * gnu/packages/python-xyz.scm (python-setuptools) [arguments]: Add phase
> setting GUIX_PYTHONPATH to source directory.
> ---
> gnu/packages/python-xyz.scm | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
> index f8afa13f33..79d01f700a 100644
> --- a/gnu/packages/python-xyz.scm
> +++ b/gnu/packages/python-xyz.scm
> @@ -1144,7 +1144,18 @@ other machines, such as over the network.")
> ;; FIXME: Tests require pytest, which itself relies on setuptools.
> ;; One could bootstrap with an internal untested setuptools.
> (arguments
> - `(#:tests? #f))
> + `(#:tests? #f
> + #:python ,python-wrapper
> + #:phases (modify-phases %standard-phases
> + ;; Use this setuptools’ sources to bootstrap themselves.
> + (add-before 'build 'set-PYTHONPATH
^ nitpick: GUIX_PYTHONPATH

Toggle quote (31 lines)
> + (lambda _
> + (format #t "current working dir ~s~%" (getcwd))
> + (setenv "GUIX_PYTHONPATH"
> + (string-append ".:" (getenv "GUIX_PYTHONPATH")))
> + #t)))))
> + ;; Not required when not building a wheel
> + ;(propagated-inputs `(("python-wheel" ,python-wheel)))
> (home-page "https://pypi.org/project/setuptools/")
> (synopsis
> "Library designed to facilitate packaging Python projects")
> --
> 2.26.2
>
>
>>From 7a99aaa40e65fde58ee2e78ad7d3e0ccd6d169ae Mon Sep 17 00:00:00 2001
> From: Lars-Dominik Braun <lars@6xq.net>
> Date: Sun, 28 Feb 2021 13:08:58 +0100
> Subject: [PATCH 05/12] python-build: Switch to PEP 517-based build
>
> * gnu/packages/python-commencement.scm: New file, containing
> python-toolchain.
> * gnu/local.mk: Add it.
> * gnu/packages/python.scm (python): Disable installing bundled
> pip/setuptools.
> * guix/build/python-build-system.scm: Rewrite using python-pypa-build.
> * guix/build-system/python.scm (default-python): Switch to
> python-toolchain
> (lower): Remove unused parameter.
>
> XXX: rationale

Forgotten XXX comment (perhaps just drop it).

Toggle quote (9 lines)
> ---
> gnu/local.mk | 1 +
> gnu/packages/python-commencement.scm | 175 +++++++++++++++++++
> gnu/packages/python.scm | 2 +-
> guix/build-system/python.scm | 8 +-
> guix/build/python-build-system.scm | 249 ++++++++++++++++++---------
> 5 files changed, 342 insertions(+), 93 deletions(-)
> create mode 100644 gnu/packages/python-commencement.scm

[...]

Toggle quote (11 lines)
> + (use-modules (ice-9 match)
> + (srfi srfi-1)
> + (srfi srfi-26)
> + (guix build union))
> +
> + (let ((out (assoc-ref %outputs "out")))
> + (union-build out (filter-map (match-lambda
> + ((_ . directory) directory))
> + %build-inputs))
> + #t))))

Note that returning #t after phases and snippets is obsolete; you can
safely take them all out now.

Toggle quote (7 lines)
> + (inputs
> + `(("python" ,python-wrapper)
> + ("python-setuptools" ,python-setuptools)
> + ("python-pip" ,python-pip))) ; XXX Maybe virtualenv/venv too? It kind of
> + ; defeats the purpose of guix, but is used
> + ; alot in local development.

I think it's OK to have people explicitly add virtualenv if they want
it, rather than grow the set of minimal packages here. I'd simply
remove the above XXX comment.

Toggle quote (12 lines)
> + (native-search-paths
> + (package-native-search-paths python))
> + (search-paths
> + (package-search-paths python))
> + (license (package-license python)) ; XXX
> + (synopsis "Python toolchain")
> + (description
> + "Python toolchain including Python itself, setuptools and pip. Use this
> +package if you need a fully-fledged Python toolchain instead of just the
> +interpreter.")
> + (home-page (package-home-page python))))

Following my above comment, perhaps s/fully-fledged/minimal/.

[...]

Toggle quote (144 lines)
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index 8e8f46467b..ca5ce667ef 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -182,7 +182,7 @@
> (list "--enable-shared" ;allow embedding
> "--with-system-expat" ;for XML support
> "--with-system-ffi" ;build ctypes
> - "--with-ensurepip=install" ;install pip and setuptools
> + "--with-ensurepip=no" ;do not install pip and setuptools
> "--enable-unicode=ucs4"
>
> ;; Prevent the installed _sysconfigdata.py from retaining a reference
> diff --git a/guix/build-system/python.scm b/guix/build-system/python.scm
> index 2bb6fa87ca..998ea9323d 100644
> --- a/guix/build-system/python.scm
> +++ b/guix/build-system/python.scm
> @@ -65,8 +65,8 @@ extension, such as '.tar.gz'."
> (define (default-python)
> "Return the default Python package."
> ;; Lazily resolve the binding to avoid a circular dependency.
> - (let ((python (resolve-interface '(gnu packages python))))
> - (module-ref python 'python-wrapper)))
> + (let ((python (resolve-interface '(gnu packages python-commencement))))
> + (module-ref python 'python-toolchain-for-build)))
>
> (define (default-python2)
> "Return the default Python 2 package."
> @@ -172,8 +172,6 @@ pre-defined variants."
> (define* (python-build store name inputs
> #:key
> (tests? #t)
> - (test-target "test")
> - (use-setuptools? #t)
> (configure-flags ''())
> (phases '(@ (guix build python-build-system)
> %standard-phases))
> @@ -199,9 +197,7 @@ provides a 'setup.py' file as its build system."
> source))
> #:configure-flags ,configure-flags
> #:system ,system
> - #:test-target ,test-target
> #:tests? ,tests?
> - #:use-setuptools? ,use-setuptools?
> #:phases ,phases
> #:outputs %outputs
> #:search-paths ',(map search-path-specification->sexp
> diff --git a/guix/build/python-build-system.scm b/guix/build/python-build-system.scm
> index 8ade1d5911..a5731511a9 100644
> --- a/guix/build/python-build-system.scm
> +++ b/guix/build/python-build-system.scm
> @@ -34,6 +34,7 @@
> #:use-module (ice-9 format)
> #:use-module (srfi srfi-1)
> #:use-module (srfi srfi-26)
> + #:use-module (srfi srfi-35)
> #:export (%standard-phases
> add-installed-pythonpath
> site-packages
> @@ -108,30 +109,17 @@
> ;; "--single-version-externally-managed" is set, thus the .egg-info directory
> ;; and the scripts defined in entry-points will always be created.
>
> +;; Base error type.
> +(define-condition-type &python-build-error &error
> + python-build-error?)
>
> -(define setuptools-shim
> - ;; Run setup.py with "setuptools" being imported, which will patch
> - ;; "distutils". This is needed for packages using "distutils" instead of
> - ;; "setuptools" since the former does not understand the
> - ;; "--single-version-externally-managed" flag.
> - ;; Python code taken from pip 9.0.1 pip/utils/setuptools_build.py
> - (string-append
> - "import setuptools, tokenize;__file__='setup.py';"
> - "f=getattr(tokenize, 'open', open)(__file__);"
> - "code=f.read().replace('\\r\\n', '\\n');"
> - "f.close();"
> - "exec(compile(code, __file__, 'exec'))"))
> -
> -(define (call-setuppy command params use-setuptools?)
> - (if (file-exists? "setup.py")
> - (begin
> - (format #t "running \"python setup.py\" with command ~s and parameters ~s~%"
> - command params)
> - (if use-setuptools?
> - (apply invoke "python" "-c" setuptools-shim
> - command params)
> - (apply invoke "python" "./setup.py" command params)))
> - (error "no setup.py found")))
> +;; Raised when 'check cannot find a valid test system in the inputs.
> +(define-condition-type &test-system-not-found &python-build-error
> + test-system-not-found?)
> +
> +;; Raised when multiple wheels are created by 'build.
> +(define-condition-type &cannot-extract-multiple-wheels &python-build-error
> + cannot-extract-multiple-wheels?)
>
> (define* (sanity-check #:key tests? inputs outputs #:allow-other-keys)
> "Ensure packages depending on this package via setuptools work properly,
> @@ -142,23 +130,51 @@ without errors."
> (with-directory-excursion "/tmp"
> (invoke "python" sanity-check.py (site-packages inputs outputs)))))
>
> -(define* (build #:key use-setuptools? #:allow-other-keys)
> +(define* (build #:key outputs #:allow-other-keys)
> "Build a given Python package."
> - (call-setuppy "build" '() use-setuptools?)
> +
> + (define pyproject-build (which "pyproject-build"))
> +
> + (define (build-pep517)
> + ;; XXX: should probably use a different path, outside of source directory,
> + ;; maybe secondary output “wheel”?
> + (mkdir-p "dist")
> + (invoke pyproject-build "--outdir" "dist" "--no-isolation" "--wheel" "."))
> +
> + ;; XXX Would be nice, if we could use bdist_wheel here to remove extra
> + ;; code path in 'install, but that depends on python-wheel.
> + (define (build-setuptools)
> + (invoke "python" "setup.py" "build"))
> +
> + (if pyproject-build
> + (build-pep517)
> + (build-setuptools))
> #t)
>
> -(define* (check #:key tests? test-target use-setuptools? #:allow-other-keys)
> +(define* (check #:key inputs outputs tests? #:allow-other-keys)
> "Run the test suite of a given Python package."
> (if tests?
> - ;; Running `setup.py test` creates an additional .egg-info directory in
> - ;; build/lib in some cases, e.g. if the source is in a sub-directory
> - ;; (given with `package_dir`). This will by copied to the output, too,
> - ;; so we need to remove.
> - (let ((before (find-files "build" "\\.egg-info$" #:directories? #t)))
> - (call-setuppy test-target '() use-setuptools?)
> - (let* ((after (find-files "build" "\\.egg-info$" #:directories? #t))
> - (inter (lset-difference string=? after before)))
> - (for-each delete-file-recursively inter)))
> + ;; Unfortunately with PEP 517 there is no common method to specify test
> + ;; systems. Guess test system based on inputs instead.
> + (let ((pytest (which "pytest"))
> + (have-setup-py (file-exists? "setup.py")))
^ indentation
Toggle quote (3 lines)
> + ;; Prefer pytest
> + ;; XXX: support nose

You can remove this; nose is stale/deprecated.

Toggle quote (6 lines)
> + (cond
> + (pytest
> + (begin
> + (format #t "using pytest~%")
> + (invoke pytest "-vv"))) ; XXX: support skipping tests based on name/extra arguments?

We could have a #:test-command argument to specify an arbitrary command
as a list of strings, such as used by the emacs-build-system; that'd
allow us to avoid overriding the phase just to add a '-k "not
this-test"' or similar.

Toggle quote (9 lines)
> + ;; 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`?
> + (have-setup-py
> + (begin
> + (format #t "using setup.py~%")
> + (invoke "python" "setup.py" "test" "-v")))

As Marius noted, falling back to 'python setup.py test' is not
desirable; it's scheduled to be removed already.

Toggle quote (42 lines)
> + ;; The developer should explicitly disable tests in this case.
> + (#t (raise (condition (&test-system-not-found))))))
> (format #t "test suite not run~%"))
> #t)
>
> @@ -195,31 +211,109 @@ running checks after installing the package."
> "/bin:"
> (getenv "PATH"))))
>
> -(define* (install #:key inputs outputs (configure-flags '()) use-setuptools?
> - #:allow-other-keys)
> - "Install a given Python package."
> - (let* ((out (python-output outputs))
> - (python (assoc-ref inputs "python"))
> - (major-minor (map string->number
> - (take (string-split (python-version python) #\.) 2)))
> - (<3.7? (match major-minor
> - ((major minor)
> - (or (< major 3) (and (= major 3) (< minor 7))))))
> - (params (append (list (string-append "--prefix=" out)
> - "--no-compile")
> - (if use-setuptools?
> - ;; distutils does not accept these flags
> - (list "--single-version-externally-managed"
> - "--root=/")
> - '())
> - configure-flags)))
> - (call-setuppy "install" params use-setuptools?)
> - ;; Rather than produce potentially non-reproducible .pyc files on Pythons
> - ;; older than 3.7, whose 'compileall' module lacks the
> - ;; '--invalidation-mode' option, do not generate any.
> - (unless <3.7?
> - (invoke "python" "-m" "compileall" "--invalidation-mode=unchecked-hash"
> - out))))
> +(define* (install #:key inputs outputs (configure-flags '()) #:allow-other-keys)
> + "Install a wheel file according to PEP 427"
> + ;; See https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl
> + (let* ((site-dir (site-packages inputs outputs))
> + (out (assoc-ref outputs "out")))
> + (define (extract file)
> + "Extract wheel (ZIP file) into site-packages directory"
> + ;; Use Python’s zipfile to avoid extra dependency
Toggle quote (18 lines)
> + (invoke "python" "-m" "zipfile" "-e" file site-dir))
> +
> + (define python-hashbang
> + (string-append "#!" (assoc-ref inputs "python") "/bin/python"))
> +
> + (define (move-data source destination)
> + (mkdir-p (dirname destination))
> + (rename-file source destination))
> +
> + (define (move-script source destination)
> + "Move executable script file from .data/scripts to out/bin and replace
> +temporary hashbang"
> + (move-data source destination)
> + ;; ZIP does not save/restore permissions, make executable
> + ;; XXX: might not be a file, but directory with subdirectories
> + (chmod destination #o755)
> + (substitute* destination (("#!python") python-hashbang)))

It seems the directory case should be handled? Otherwise the
substitute* call would error out upon encountering it.

Toggle quote (45 lines)
> + ;; Python’s distutils.command.install defines this mapping from source to
> + ;; destination mapping.
> + (define install-schemes
> + `(("scripts" "bin" ,move-script)
> + ;; XXX: Why does Python not use share/ here?
> + ("data" "share" ,move-data)))
> +
> + (define (expand-data-directory directory)
> + "Move files from all .data subdirectories to their respective
> +destinations."
> + (for-each
> + (match-lambda ((source destination function)
> + (let ((source-path (string-append directory "/" source))
> + (destination-path (string-append out "/" destination)))
> + (when (file-exists? source-path)
> + (begin
> + ;; This assumes only files exist in the scripts/ directory.
> + (for-each
> + (lambda (file)
> + (apply
> + function
> + (list
> + (string-append source-path "/" file)
> + (string-append destination-path "/" file))))
> + (scandir source-path (negate (cut member <> '("." "..")))))
> + (rmdir source-path))))))
> + install-schemes))
> +
> + (define pyproject-build (which "pyproject-build"))
> +
> + (define (list-directories base predicate)
> + ;; Cannot use find-files here, because it’s recursive.
> + (scandir
> + base
> + (lambda (name)
> + (let ((stat (lstat (string-append base "/" name))))
> + (and
> + (not (member name '("." "..")))
> + (eq? (stat:type stat) 'directory)
> + (predicate name stat))))))
> +
> + (define (install-pep517)
> + "Install a wheel generated by a PEP 517-compatible builder."
> + (let ((wheels (find-files "dist" "\\.whl$"))) ; XXX: do not recurse

If we do not want to recurse, we should use scandir?

Toggle quote (27 lines)
> + (when (> (length wheels) 1) ; This code does not support multiple wheels
> + ; yet, because their outputs would have to be
> + ; merged properly.
> + (raise (condition (&cannot-extract-multiple-wheels))))
> + (for-each extract wheels))
> + (let ((datadirs (map
> + (cut string-append site-dir "/" <>)
> + (list-directories site-dir (file-name-predicate "\\.data$")))))
> + (for-each (lambda (directory)
> + (expand-data-directory directory)
> + (rmdir directory))
> + datadirs)))
> +
> + (define (install-setuptools)
> + "Install using setuptools."
> + (let ((out (assoc-ref outputs "out")))
> + (invoke "python" "setup.py"
> + "install"
> + "--prefix" out
> + "--single-version-externally-managed"
> + "--root=/")))
> +
> + (if pyproject-build
> + (install-pep517)
> + (install-setuptools))
> + #t))

So, IIUC, this complicated install phase is because we no longer take
'pip' for granted and is only later available, built from this very
build system, right? Otherwise installing a wheel with pip would be
trivial (c.f. python-isort).

Toggle quote (8 lines)
> +
> +(define* (compile-bytecode #:key inputs outputs (configure-flags '()) #:allow-other-keys)
> + "Compile installed byte-code in site-packages."
> + (let ((site-dir (site-packages inputs outputs)))
> + (invoke "python" "-m" "compileall" site-dir)
> + ;; XXX: We could compile with -O and -OO too here, at the cost of more space.
> + #t))

I think you can drop that comment; the default sounds reasonable:

-o OPT_LEVELS Optimization levels to run compilation with.
This message was truncated. Download the full message here.
L
L
Lars-Dominik Braun wrote on 23 Jan 2022 11:21
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 46848@debbugs.gnu.org)
Ye0sHWa6/LM4uHuT@noor.fritz.box
Hi Maxim,

Toggle quote (2 lines)
> Here's a review of patches 1 to 6.

thanks for the review. Unfortunately this is not the most recent
proposal and I have no way to retract the previous patches. I pushed v3
to the wip-python-pep517 branch, because of the sheer number of patches
and so the CI could build it (since it requires a rebuild of the entire
rust bootstrap chain).

Toggle quote (5 lines)
> > + ;; Prefer pytest
> > + ;; XXX: support nose
>
> You can remove this; nose is stale/deprecated.

So it’s preferred to replace 'check in cases where python-nose is
still in use?

Toggle quote (12 lines)
>
> > + (cond
> > + (pytest
> > + (begin
> > + (format #t "using pytest~%")
> > + (invoke pytest "-vv"))) ; XXX: support skipping tests based on name/extra arguments?
>
> We could have a #:test-command argument to specify an arbitrary command
> as a list of strings, such as used by the emacs-build-system; that'd
> allow us to avoid overriding the phase just to add a '-k "not
> this-test"' or similar.

I added #:test-flags in my v3 proposal.

Toggle quote (12 lines)
> > + ;; 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`?
> > + (have-setup-py
> > + (begin
> > + (format #t "using setup.py~%")
> > + (invoke "python" "setup.py" "test" "-v")))
>
> As Marius noted, falling back to 'python setup.py test' is not
> desirable; it's scheduled to be removed already.

Sure, but using `python -m unittest` instead requires some investigation.

Toggle quote (12 lines)
> > + (define (move-script source destination)
> > + "Move executable script file from .data/scripts to out/bin and replace
> > +temporary hashbang"
> > + (move-data source destination)
> > + ;; ZIP does not save/restore permissions, make executable
> > + ;; XXX: might not be a file, but directory with subdirectories
> > + (chmod destination #o755)
> > + (substitute* destination (("#!python") python-hashbang)))
>
> It seems the directory case should be handled? Otherwise the
> substitute* call would error out upon encountering it.

I have not seen anyone using subdirectories in bin/ yet. Is that
supported anywhere?

Toggle quote (5 lines)
> So, IIUC, this complicated install phase is because we no longer take
> 'pip' for granted and is only later available, built from this very
> build system, right? Otherwise installing a wheel with pip would be
> trivial (c.f. python-isort).

If we want to bootstrap these two packages easily (and possibly start
unvendoring their vendored dependencies later), they cannot be part of
this build system and thus we need to implement building/installing
ourselves. I tried using pypa-build in an earlier version, but the
bootstrap chain is unmaintainable.

There also is a project called installer[1], but it does not have a
CLI yet.

Cheers,
Lars

M
M
Maxim Cournoyer wrote on 26 Feb 2022 15:10
Re: [bug#46848] [PATCHES] [core-updates] PEP 517 python-build-system
(name . Lars-Dominik Braun)(address . lars@6xq.net)
87h78lwwfc.fsf@gmail.com
Hi Lars-Dominik,

Lars-Dominik Braun <lars@6xq.net> writes:

When you judge the branch ready to merge, could you please send a subset
of the patches (at least the ones touching the python-build-system
directly) to this issue (marked as v2 -- git send-email -v2) so that
they can be more easily commented?

Thanks,

Maxim
L
L
Lars-Dominik Braun wrote on 28 Feb 2022 20:25
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
Yh0hr6TPjAX7cowW@noor.fritz.box
Hi Maxim,

Toggle quote (5 lines)
> When you judge the branch ready to merge, could you please send a subset
> of the patches (at least the ones touching the python-build-system
> directly) to this issue (marked as v2 -- git send-email -v2) so that
> they can be more easily commented?

as soon as time permits I can do that. Which route do we want to
take? Replace python-build-system entirely in one big merge or add a
new one and slowly migrate?

Cheers,
Lars
M
M
Maxim Cournoyer wrote on 28 Feb 2022 23:32
(name . Lars-Dominik Braun)(address . lars@6xq.net)
878rtusju1.fsf@gmail.com
Hi Lars,

Lars-Dominik Braun <lars@6xq.net> writes:

Toggle quote (11 lines)
> Hi Maxim,
>
>> When you judge the branch ready to merge, could you please send a subset
>> of the patches (at least the ones touching the python-build-system
>> directly) to this issue (marked as v2 -- git send-email -v2) so that
>> they can be more easily commented?
>
> as soon as time permits I can do that. Which route do we want to
> take? Replace python-build-system entirely in one big merge or add a
> new one and slowly migrate?

After the Berlin can be rebooted onto its new file system, I expect it
should allow us to keep the build farm much busier than in the past give
us the headroom to experiment with a PEP 517-focused world rebuilding
branch.

I'd aim to have the build system completely replaced; unless your
experience suggests it's going to take multiple weeks to fix iron out
the kinks?

Thanks,

Maxim
L
L
Lars-Dominik Braun wrote on 24 Apr 2022 11:13
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
YmUUw8u0rTL6GU5Y@noor.fritz.box
Hi Maxim,

Toggle quote (4 lines)
> When you judge the branch ready to merge, could you please send a subset
> of the patches (at least the ones touching the python-build-system
> directly) to this issue (marked as v2 -- git send-email -v2) so that
> they can be more easily commented?
I had some time to finish my work, so I pushed all of my changes to
wip-python-pep517 and attached changes that do not fix individual packages
to this email. Since my last version I added support for building Python
2 packages, although we should really phase out Python 2 asap. I kept
support for nose and setup.py’s test target, because they are still
in use/valuable, but we can also remove them if you prefer.

Please have a look when time permits. If all is good we can move on to
fix failing packages.

Thank you very much,
Lars
From 720dbe22d431262938be29dd9a9ddb78c44a99b3 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Fri, 19 Feb 2021 17:22:35 +0100
Subject: [PATCH v3 001/150] build/python: Handle missing setuptools in
sanity-check.py

Just skip testing if required dependencies (setuptools) are not
available.

* gnu/packages/aux-files/python/sanity-check.py: Handle ImportError.
---
gnu/packages/aux-files/python/sanity-check.py | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

Toggle diff (21 lines)
diff --git a/gnu/packages/aux-files/python/sanity-check.py b/gnu/packages/aux-files/python/sanity-check.py
index 182133bb3d..1366b68e3d 100644
--- a/gnu/packages/aux-files/python/sanity-check.py
+++ b/gnu/packages/aux-files/python/sanity-check.py
@@ -19,9 +19,13 @@
from __future__ import print_function # Python 2 support.
import importlib
-import pkg_resources
import sys
import traceback
+try:
+ import pkg_resources
+except ImportError:
+ print('Warning: Skipping, because python-setuptools are not available.')
+ sys.exit(0)
try:
from importlib.machinery import PathFinder
--
2.35.1
From 84c3af5cf41d402847adb33b11897d34f5a14179 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun <lars@6xq.net>
Date: Wed, 19 Jan 2022 09:48:44 +0100
Subject: [PATCH v3 146/150] gnu: meson: Match shebang instead of
setuptools-specific line.

* gnu/packages/build-tools.scm (meson)[arguments]: Replace substitute*
pattern.
---
gnu/packages/build-tools.scm | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

Toggle diff (23 lines)
diff --git a/gnu/packages/build-tools.scm b/gnu/packages/build-tools.scm
index 437b0d3550..b343467699 100644
--- a/gnu/packages/build-tools.scm
+++ b/gnu/packages/build-tools.scm
@@ -289,12 +289,12 @@ (define-public meson
(python-version (assoc-ref inputs "python")))
(output (assoc-ref outputs "out")))
(substitute* (string-append output "/bin/meson")
- (("# EASY-INSTALL-ENTRY-SCRIPT")
- (format #f "\
+ (("#!/(.+)" all)
+ (format #f "~a\
import sys
sys.path.insert(0, '~a/lib/python~a/site-packages')
-# EASY-INSTALL-ENTRY-SCRIPT"
- output python-version)))))))))
+"
+ all output python-version)))))))))
(inputs (list python-wrapper ninja))
(home-page "https://mesonbuild.com/")
(synopsis "Build system designed to be fast and user-friendly")
--
2.35.1
L
L
Lars-Dominik Braun wrote on 24 Apr 2022 11:22
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
YmUWxCyBWFDY78Pz@noor.fritz.box
Hey again,

sorry for the noise. During one of my many rebases I missed to add a
file that should have been included in patch 3. See attached patch.

Cheers,
Lars
M
M
Maxim Cournoyer wrote on 11 Jan 2023 16:41
Re: bug#46848: [PATCHES] [core-updates] PEP 517 python-build-system
(name . Marius Bakke)(address . marius@gnu.org)
87v8ldhyer.fsf_-_@gmail.com
Hello!

With the pyproject build system now in master, can we close this issue?

--
Thanks,
Maxim
L
L
Lars-Dominik Braun wrote on 10 Feb 2023 11:13
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
Y+YYzwO3Ga2eMDGZ@noor.fritz.box
Hi,

Toggle quote (1 lines)
> With the pyproject build system now in master, can we close this issue?
yes, I think so.

Cheers,
Lars
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 46848@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 46848
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch