public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: "Michał Górny" <mgorny@gentoo.org>
Subject: [gentoo-dev] [PATCH 2/2] distutils-r1.eclass: Allow DISTUTILS_UPSTREAM_PEP517=standalone
Date: Sat, 10 May 2025 14:50:55 +0200	[thread overview]
Message-ID: <20250510125055.757640-2-mgorny@gentoo.org> (raw)
In-Reply-To: <20250510125055.757640-1-mgorny@gentoo.org>

Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 eclass/distutils-r1.eclass | 35 +++++++++++++++++++++++++++++------
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index d32e5929177e..7dfc8c7a3c30 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -134,13 +134,20 @@
 #
 # - sip - sipbuild backend
 #
-# - standalone - standalone build systems without external deps
-#   (used for bootstrapping).
+# - standalone - standalone/local build systems
 #
 # - uv-build - uv-build backend (using dev-python/uv)
 #
-# The variable needs to be set before the inherit line.  The eclass
-# adds appropriate build-time dependencies and verifies the value.
+# The variable needs to be set before the inherit line.  If another
+# value than "standalone" and "no" is used, The eclass adds appropriate
+# build-time dependencies, verifies the value and calls the appropriate
+# modern entry point for the backend.  With DISTUTILS_UPSTREAM_PEP517,
+# this variable can be used to override the upstream build backend.
+#
+# The value of "standalone" indicates that upstream is using a custom,
+# local build backend.  In this mode, the eclass does not add any
+# dependencies, disables build backend verification and uses the exact
+# entry point listed in pyproject.toml.
 #
 # The special value "no" indicates that the package has no build system.
 # This is not equivalent to unset DISTUTILS_USE_PEP517 (legacy mode).
@@ -162,6 +169,12 @@
 # overriden to workaround the eclass check, when it is desirable
 # to build the wheel using other backend than the one used upstream.
 #
+# When using it, ideally it should list the build backend actually used
+# upstream, so the eclass will throw an error if that backend changes
+# (and therefore overrides may need to change as well).  As a special
+# case, setting it to "standalone" disables the check entirely (while
+# still forcing the backend, unlike DISTUTILS_USE_PEP517=standalone).
+#
 # Please note that even in packages using PEP621 metadata, there can
 # be subtle differences between the behavior of different PEP517 build
 # backends, for example regarding finding package files.  When using
@@ -1150,11 +1163,23 @@ _distutils-r1_get_backend() {
 		fi
 	fi
 
+	# if DISTUTILS_USE_PEP517 is "standalone", we respect the exact
+	# backend used in pyproject.toml; otherwise we force the backend
+	# based on DISTUTILS_USE_PEP517
 	if [[ ${DISTUTILS_USE_PEP517} == standalone ]]; then
 		echo "${build_backend}"
 		return
 	fi
 
+	# we can output it early, even if we die below
+	echo "$(_distutils-r1_key_to_backend "${DISTUTILS_USE_PEP517}")"
+
+	# skip backend verification if DISTUTILS_UPSTREAM_PEP517
+	# is "standalone"
+	if [[ ${DISTUTILS_UPSTREAM_PEP517} == standalone ]]; then
+		return
+	fi
+
 	# verify that the ebuild correctly specifies the build backend
 	local expected_backend=$(
 		_distutils-r1_key_to_backend \
@@ -1189,8 +1214,6 @@ _distutils-r1_get_backend() {
 			> "${T}"/.distutils_deprecated_backend_warned || die
 		fi
 	fi
-
-	echo "$(_distutils-r1_key_to_backend "${DISTUTILS_USE_PEP517}")"
 }
 
 # @FUNCTION: distutils_wheel_install


      reply	other threads:[~2025-05-10 12:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-10 12:50 [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: Fix pyvenv correctly for Python 3.14 Michał Górny
2025-05-10 12:50 ` Michał Górny [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250510125055.757640-2-mgorny@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox