From: Marius Bakke <marius@gnu.org>
To: zimoun <zimon.toutoune@gmail.com>, 58587@debbugs.gnu.org
Cc: Lars-Dominik Braun <lars@6xq.net>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: [bug#58587] [PATCH 00/14] Introducing pyproject-build-system.
Date: Tue, 18 Oct 2022 23:51:47 +0200 [thread overview]
Message-ID: <877d0wvlzg.fsf@gnu.org> (raw)
In-Reply-To: <86sfjlzdbn.fsf@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1530 bytes --]
zimoun <zimon.toutoune@gmail.com> skriver:
> Hi Marius,
>
> On Mon, 17 Oct 2022 at 22:06, Marius Bakke <marius@gnu.org> wrote:
>
>> I plan to eventually merge it with python-build-system instead of
>> keeping it separate. Thoughts?
>
> I would suggest to have a clear plan about this transition strategy. :-)
> I mean, if we go to two separated Python build-systems and then merge
> them, we have to write down the various steps; otherwise it could be
> quickly a mess.
>
> For example,
>
> 1. advertise about this new Python build-system
> 2. recommend only this new
> 3. only include package using this new
> 4. convert from old to new
> 5. remove old / rename old to new
>
> or whatever else. My concern is to have two build systems to maintain
> on the long term.
>
> Once something lands to master and the API, it is then hard to modify.
> Therefore, it appears to me better to draw beforehand the large lines of
> this transition plan.
I tried to address this in the attached documentation patch.
The idea is to:
* Recommend it for new packages in the 'guix' channel, mostly during
patch review.
* Once we are confident in the implementation, remove the "experimental"
status and recommend it in the documentation.
* Merge pieces of it into python-build-system as we go, such as sanity
check changes, using python-toolchain, etc.
* When we "know" that there won't be any major regressions, swap out
python-build-system with pyproject-build-system entirely and mark the
latter as deprecated.
Thoughts?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-doc-Document-pyproject-build-system.patch --]
[-- Type: text/x-patch, Size: 4043 bytes --]
From 628944b6f4267c4eeb5884074298b82c8d17548c Mon Sep 17 00:00:00 2001
From: Marius Bakke <marius@gnu.org>
Date: Tue, 18 Oct 2022 23:38:39 +0200
Subject: [PATCH] doc: Document pyproject-build-system.
* doc/guix.texi (Build Systems): Add pyproject-build-system section.
* doc/contributing.texi (Python Modules): Mention pyproject.toml and the
PYTHON-TOOLCHAIN package.
---
doc/contributing.texi | 21 +++++++++++++--------
doc/guix.texi | 14 ++++++++++++++
2 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 4b1eed1cb1..b9260267fa 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -791,7 +791,9 @@ described above.
Dependency information for Python packages is usually available in the
package source tree, with varying degrees of accuracy: in the
-@file{setup.py} file, in @file{requirements.txt}, or in @file{tox.ini}.
+@file{pyproject.toml} file, the @file{setup.py} file, in
+@file{requirements.txt}, or in @file{tox.ini} (the latter mostly for
+test dependencies).
Your mission, when writing a recipe for a Python package, is to map
these dependencies to the appropriate type of ``input'' (@pxref{package
@@ -802,10 +804,12 @@ following check list to determine which dependency goes where.
@itemize
@item
-We currently package Python 2 with @code{setuptools} and @code{pip}
-installed like Python 3.4 has per default. Thus you don't need to
-specify either of these as an input. @command{guix lint} will warn you
-if you do.
+We currently package Python with @code{setuptools} and @code{pip}
+installed per default. This is about to change, and users are encouraged
+to use @code{python-toolchain} if they want a build environment for Python.
+
+@command{guix lint} will warn if @code{setuptools} or @code{pip} are
+added as native-inputs because they are generally not necessary.
@item
Python dependencies required at run time go into
@@ -814,9 +818,10 @@ Python dependencies required at run time go into
@file{requirements.txt} file.
@item
-Python packages required only at build time---e.g., those listed with
-the @code{setup_requires} keyword in @file{setup.py}---or only for
-testing---e.g., those in @code{tests_require}---go into
+Python packages required only at build time---e.g., those listed under
+@code{build-system.requires} in @file{pyproject.toml} or with the
+@code{setup_requires} keyword in @file{setup.py}---or dependencies only
+for testing---e.g., those in @code{tests_require} or @file{tox.ini}---go into
@code{native-inputs}. The rationale is that (1) they do not need to be
propagated because they are not needed at run time, and (2) in a
cross-compilation context, it's the ``native'' input that we'd want.
diff --git a/doc/guix.texi b/doc/guix.texi
index f0fb383005..145aa16afd 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -9311,7 +9311,21 @@ instead of the default @code{"out"} output. This is useful for packages that
include a Python package as only a part of the software, and thus want to
combine the phases of @code{python-build-system} with another build system.
Python bindings are a common usecase.
+@end defvr
+
+@defvr {Scheme Variable} pyproject-build-system
+This is a variable exported by @code{guix build-system pyproject}. It
+is a reimplementation of @code{python-build-system} designed around
+@file{pyproject.toml} and @url{https://peps.python.org/pep-0517/, PEP 517},
+and supports a variety of build backends and test frameworks.
+
+It is considered ``experimental'' in that the implementation details are
+not set in stone yet, however users are encouraged to try it for new
+Python projects (even those using @file{setup.py}) and there should not
+be any breaking changes.
+Eventually this build system will be deprecated and merged back into
+@code{python-build-system}, probably some time in 2024.
@end defvr
@defvr {Scheme Variable} perl-build-system
--
2.38.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]
next prev parent reply other threads:[~2022-10-18 21:52 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 20:06 [bug#58587] [PATCH 00/14] Introducing pyproject-build-system Marius Bakke
2022-10-17 20:11 ` [bug#58587] [PATCH 01/14] gnu: python-setuptools: Move to python-build Marius Bakke
2022-10-17 20:11 ` [bug#58587] [PATCH 02/14] gnu: pypy: Move to separate module Marius Bakke
2022-10-27 13:28 ` Maxim Cournoyer
2022-10-17 20:11 ` [bug#58587] [PATCH 03/14] gnu: python-pip: Move to (gnu packages python-build) Marius Bakke
2022-10-27 13:29 ` Maxim Cournoyer
2022-10-17 20:11 ` [bug#58587] [PATCH 04/14] build-system: Add pyproject-build-system Marius Bakke
2022-10-27 14:23 ` Maxim Cournoyer
2022-10-27 15:17 ` Lars-Dominik Braun
2022-10-27 17:12 ` Maxim Cournoyer
2022-10-27 17:23 ` Marius Bakke
2022-10-27 19:32 ` bug#58587: " Marius Bakke
2022-10-28 1:12 ` [bug#58587] " Maxim Cournoyer
2022-10-17 20:11 ` [bug#58587] [PATCH 05/14] gnu: python-autopage: Use pyproject-build-system Marius Bakke
2022-10-27 14:24 ` Maxim Cournoyer
2022-10-17 20:11 ` [bug#58587] [PATCH 06/14] gnu: flair: Switch to pyproject-build-system Marius Bakke
2022-10-17 20:11 ` [bug#58587] [PATCH 07/14] gnu: python-pydyf: Use pyproject-build-system Marius Bakke
2022-10-17 20:11 ` [bug#58587] [PATCH 08/14] gnu: weasyprint: " Marius Bakke
2022-10-17 20:11 ` [bug#58587] [PATCH 09/14] gnu: python-glyphslib: " Marius Bakke
2022-10-17 20:11 ` [bug#58587] [PATCH 10/14] gnu: python-statmake: " Marius Bakke
2022-10-17 20:11 ` [bug#58587] [PATCH 11/14] gnu: python-ufolib2: " Marius Bakke
2022-10-17 20:11 ` [bug#58587] [PATCH 12/14] gnu: python-mypy-protobuf: Switch to pyproject-build-system Marius Bakke
2022-10-17 20:12 ` [bug#58587] [PATCH 13/14] gnu: python-tempora: " Marius Bakke
2022-10-17 20:12 ` [bug#58587] [PATCH 14/14] gnu: python-pygmsh: Use pyproject-build-system Marius Bakke
2022-10-27 14:26 ` Maxim Cournoyer
2022-10-27 13:25 ` [bug#58587] [PATCH 01/14] gnu: python-setuptools: Move to python-build Maxim Cournoyer
2022-10-27 14:08 ` Marius Bakke
2022-10-27 17:34 ` Maxim Cournoyer
2022-10-18 9:33 ` [bug#58587] [PATCH 00/14] Introducing pyproject-build-system zimoun
2022-10-18 21:51 ` Marius Bakke [this message]
2022-10-19 9:49 ` zimoun
2022-10-19 23:11 ` Marius Bakke
2022-10-19 23:17 ` Marius Bakke
2022-10-20 8:08 ` zimoun
2022-10-22 19:06 ` Marius Bakke
2022-10-22 19:09 ` [bug#58587] [PATCH v2 01/22] gnu: python-setuptools: Move to python-build Marius Bakke
2022-10-22 19:09 ` [bug#58587] [PATCH v2 02/22] gnu: pypy: Move to separate module Marius Bakke
2022-10-22 19:09 ` [bug#58587] [PATCH v2 03/22] gnu: python-pip: Move to (gnu packages python-build) Marius Bakke
2022-10-22 19:09 ` [bug#58587] [PATCH v2 04/22] build-system: Add pyproject-build-system Marius Bakke
2022-10-22 19:09 ` [bug#58587] [PATCH v2 05/22] news: Add entry for 'pyproject-build-system' Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 01/22] gnu: python-setuptools: Move to python-build Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 02/22] gnu: pypy: Move to separate module Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 03/22] gnu: python-pip: Move to (gnu packages python-build) Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 04/22] build-system: Add pyproject-build-system Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 05/22] news: Add entry for 'pyproject-build-system' Marius Bakke
2022-10-24 16:36 ` pelzflorian (Florian Pelz)
2022-10-24 18:01 ` Julien Lepiller
2022-10-22 22:20 ` [bug#58587] [PATCH v3 06/22] gnu: python-autopage: Use pyproject-build-system Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 07/22] gnu: flair: Switch to pyproject-build-system Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 08/22] gnu: python-pydyf: Use pyproject-build-system Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 09/22] gnu: weasyprint: " Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 10/22] gnu: python-glyphslib: " Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 11/22] gnu: python-statmake: " Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 12/22] gnu: python-ufolib2: " Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 13/22] gnu: python-mypy-protobuf: Switch to pyproject-build-system Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 14/22] gnu: python-tempora: " Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 15/22] gnu: python-pygmsh: Use pyproject-build-system Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 16/22] gnu: zabbix-cli: Switch to pyproject-build-system Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 17/22] gnu: python-openapi-schema-validator: Use pyproject-build-system Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 18/22] gnu: python-openapi-spec-validator: " Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 19/22] gnu: python-path: " Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 20/22] gnu: python-cattrs: " Marius Bakke
2022-10-22 22:20 ` [bug#58587] [PATCH v3 21/22] gnu: python-scikit-build: Switch to pyproject-build-system Marius Bakke
2022-10-22 22:21 ` [bug#58587] [PATCH v3 22/22] gnu: python-deepmerge: Use pyproject-build-system Marius Bakke
2022-10-27 13:10 ` [bug#58587] [PATCH 00/14] Introducing pyproject-build-system Maxim Cournoyer
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877d0wvlzg.fsf@gnu.org \
--to=marius@gnu.org \
--cc=58587@debbugs.gnu.org \
--cc=lars@6xq.net \
--cc=maxim.cournoyer@gmail.com \
--cc=zimon.toutoune@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).