Repository: python/peps
Pull request #4315: PEP 780: ABI features as environment markers
Author: login: zklaus
Labels: name: new-pep
description: A new draft PEP submitted for initial review
Created: 2025-03-21T12:34:22Z | Merged: 2025-03-25T20:41:42Z

<!--
You can use the following checklist when double-checking your PEP,
and you can help complete some of it yourself if you like
by ticking any boxes you're sure about, like this: [x]
If you're unsure about anything, just leave it blank and we'll take a look.

If your PEP is not Standards Track, remove the corresponding section.
-->

## Basic requirements (all PEP Types)

* [x] Read and followed [PEP 1](https://peps.python.org/1) & [PEP 12](https://peps.python.org/12)
* [x] File created from the [latest PEP template](https://github.com/python/peps/blob/main/peps/pep-0012/pep-NNNN.rst?plain=1)
* [x] PEP has next available number, & set in filename (``pep-NNNN.rst``), PR title (``PEP 123: <Title of PEP>``) and ``PEP`` header
* [x] Title clearly, accurately and concisely describes the content in 79 characters or less
* [x] Core dev/PEP editor listed as ``Author`` or ``Sponsor``, and formally confirmed their approval
* [x] ``Author``, ``Status`` (``Draft``), ``Type`` and ``Created`` headers filled out correctly
* [x] ``PEP-Delegate``, ``Topic``, ``Requires`` and ``Replaces`` headers completed if appropriate
* [x] Required sections included
    * [x] Abstract (first section)
    * [x] Copyright (last section; exact wording from template required)
* [x] Code is well-formatted (PEP 7/PEP 8) and is in [code blocks, with the right lexer names](https://peps.python.org/pep-0012/#literal-blocks) if non-Python
* [x] PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
* [x] Authors/sponsor added to ``.github/CODEOWNERS`` for the PEP


## Standards Track requirements

* [x] PEP topic [discussed in a suitable venue](https://peps.python.org/pep-0001/#start-with-an-idea-for-python) with general agreement that a PEP is appropriate
* [x] [Suggested sections](https://peps.python.org/pep-0012/#suggested-sections) included (unless not applicable)
    * [x] Motivation
    * [x] Rationale
    * [x] Specification
    * [x] Backwards Compatibility
    * [x] Security Implications
    * [x] How to Teach This
    * [x] Reference Implementation
    * [x] Rejected Ideas
    * [x] Open Issues
* [x] ``Python-Version`` set to valid (pre-beta) future Python version, if relevant
* [ ] Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
* [ ] Right before or after initial merging, [PEP discussion thread](https://peps.python.org/pep-0001/#discussing-a-pep) created and linked to in ``Discussions-To`` and ``Post-History``


<!-- readthedocs-preview pep-previews start -->
----
📚 Documentation preview 📚: https://pep-previews--4315.org.readthedocs.build/

<!-- readthedocs-preview pep-previews end -->


Diff:
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index d22fd902dc3..bcbaacbfaf1 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -658,6 +658,7 @@ peps/pep-0775.rst  @encukou
 peps/pep-0777.rst  @warsaw
 # ...
 peps/pep-0779.rst  @Yhg1s @colesbury @mpage
+peps/pep-0780.rst  @lysnikolaou
 # ...
 peps/pep-0789.rst  @njsmith
 # ...
diff --git a/peps/pep-0780.rst b/peps/pep-0780.rst
new file mode 100644
index 00000000000..5510dafea17
--- /dev/null
+++ b/peps/pep-0780.rst
@@ -0,0 +1,451 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `addition to the Python Standard Library <pep-780-sys.abi_features_>`_
+in the form of a new attribute :data:`!sys.abi_features`, as well as for
+`environment markers <pep-780-sys_abi_features_>`_ as a new marker variable,
+``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Relation to Other PEPs
+----------------------
+
+This PEP extends environment markers with set semantics for ABI features.
+:pep:`751#additions-to-marker-expression-syntax` includes a similar extension
+for lock file specific environment markers; although the two have been
+developed indepedently, they are compatible where they overlap in terms of the
+new set semantics.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+ABI Features
+------------
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+.. _pep-780-sys.abi_features:
+
+The :data:`!sys.abi_features` Attribute
+---------------------------------------
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so, and ``sys.abiflags`` is
+not available on Windows.
+Hence, the `ABI Features`_ listed above are added to the Python standard
+library.
+
+Since they are all the result of compile time choices describing basic features
+of the interpreter, the most intuitive place to put them is in ``sys``.
+Since there is no intrinsic order, nor a possibility for duplication, they are
+added as a ``frozenset`` of strings.
+
+All Python interpreters MUST provide the ``sys.abi_features`` attribute as a
+``frozenset`` of strings, which MUST contain only the `ABI Features`_ that are
+defined in this PEP or in a subsequent PEP.
+
+An example value would be ``sys.abi_features == frozenset({"free-threading",
+"debug", "32-bit"})`` on a free-threaded debug build for win32.
+
+.. _pep-780-sys_abi_features:
+
+The ``sys_abi_features`` Environment Marker
+-------------------------------------------
+
+To make ABI features available in dependency specifications, a new environment
+marker variable, ``sys_abi_features``, is added to the format of dependency
+specifiers with the same semantics as the ``sys.abi_features`` attribute
+proposed above.
+
+To do this, we need to extend the grammar laid out in :pep:`508` and maintained
+in the :ref:`packaging:dependency-specifiers` and document the possible values.
+
+The grammar is extended to include the ``sys_abi_features`` marker variable by
+augmenting the definition of ``env_var`` as follows::
+
+    env_var       = ('python_version' | 'python_full_version' |
+                     'os_name' | 'sys_platform' | 'platform_release' |
+                     'platform_system' | 'platform_version' |
+                     'platform_machine' | 'platform_python_implementation' |
+                     'implementation_name' | 'implementation_version' |
+                     'sys_abi_features' |
+                     'extra' # ONLY when defined by a containing layer
+                     )
+
+Like the grammar, also the overview table of environment markers in
+:ref:`packaging:dependency-specifiers` is augmented to add the following row:
+
+.. list-table::
+    :header-rows: 1
+
+    * - Marker
+      - Python equivalent
+      - Sample values
+    * - ``sys_abi_features``
+      - ``sys.abi_features`` [#sys-abi-features]_
+      - ``frozenset()``, ``frozenset({'free-threading', '64-bit'})``,
+        ``frozenset({'gil-enabled', 'debug', '32-bit'})``
+
+With these additions, ABI features can be used in dependency specifications via
+the ``in`` operator to test for the presence of a feature, or the ``not in``
+operator to test for the absence of a feature.
+
+Note that the presence of ``sys.abi_features`` in the Python standard library
+makes implementation particularly easy for new Python versions, but its absence
+in older versions does not prevent the implementation of the new environment
+markers, as demonstrated in the `Reference Implementation`_.
+
+Examples
+========
+
+Require Cython Pre-release for Free-Threaded Python
+----------------------------------------------------
+To require a pre-release of Cython only for a free-threaded Python
+interpreter, the following dependency specification can be used::
+
+    cython >3.1.0a1; "free-threading" in sys_abi_features
+    cython ==3.0.*; "free-threading" not in sys_abi_features
+
+Require SciPy Unless on 32-bit ``win32``
+----------------------------------------
+To require SciPy unless on a 32-bit interpreter on Windows, the following
+dependency specification can be used::
+
+    scipy; platform_system != "Windows" or "32-bit" not in sys_abi_features
+
+Require NumPy for a Free-Threaded Interpreter With Debugging Capabilities
+--------------------------------------------------------------------------
+To require NumPy only for a free-threaded interpreter with debugging
+capabilities, the following dependency can be used::
+
+    numpy; "free-threading" in sys_abi_features and "debug" in sys_abi_features
+
+Backwards Compatibility
+=======================
+
+This is a pure extension to the existing environment markers and does not
+affect existing environment markers or dependency specifications, hence there
+are no direct backwards compatibility concerns.
+
+However, the introduction of the feature has implications for a
+number of ecosystem tools, especially those which attempt to support
+examination of data in ``pyproject.toml`` and ``requirements.txt``.
+
+Audit and Update Tools
+----------------------
+
+A wide range of tools understand Python dependency data as expressed in
+``requirements.txt`` files. (e.g., Dependabot, Tidelift, etc)
+
+Such tools inspect dependency data and, in some cases, offer tool-assisted or
+fully automated updates.
+It is our expectation that no such tools would support the new environment
+markers at first, and broad ecosystem support could take many months or even
+some number of years to arrive.
+
+As a result, users of the new environment markers would experience a
+degradation in their workflows and tool support at the time that they start
+using them. This is true of any new standard for where and how dependency data
+are encoded.
+
+Security Implications
+=====================
+
+This PEP introduces new syntax for specifying dependency information in
+projects. However, it does not introduce newly specified mechanisms for
+handling or resolving dependencies.
+
+It therefore does not carry security concerns other than those inherent in any
+tools which may already be used to install dependencies---i.e. malicious
+dependencies may be specified here, just as they may be specified in
+``requirements.txt`` files.
+
+How to Teach This
+=================
+
+The use of environment markers is well established and communicated chiefly
+in :ref:`packaging:dependency-specifiers`.
+The new environment marker can be introduced in the same document.
+Additionally, both for package authors and users, free-threading specific
+guidance can be provided at the `Python free-threading guide`_.
+The new ``sys.abi_features`` attribute will be documented in the Python
+standard library documentation.
+
+
+Reference Implementation
+========================
+
+The reference implementation for the ``sys.abi_features`` attribute can be
+found in `Add abi_features to sys
+<https://github.com/zklaus/cpython/pull/1>`__.
+
+The reference implementation for the environment markers is available in a fork
+of the ``packaging`` library at `Environment markers for ABI features
+<https://github.com/zklaus/packaging/pull/1>`__.
+
+`A demonstration package <https://github.com/zklaus/env-marker-example>`__ is
+also available.
+
+Since ``pip`` uses a vendored copy of ``packaging`` internally, we also provide
+`a patched version of pip`__, which replaces the vendored ``packaging`` with the
+reference implementation linked above.
+
+__ https://github.com/zklaus/pip/tree/env-marker-free-threading
+
+Rejected Ideas
+==============
+
+Extension Mechanism
+-------------------
+
+In an early discussion of the topic (`Environment marker for free-threading`_),
+the idea of a general extension mechanism for environment markers was brought
+up. While it is appealing to forego a whole PEP process should the need for
+new environment markers arise in the future, there are two main challenges.
+First, a completely dynamic mechanism would present difficulties for tools that
+rely on static analysis of dependency specifications.
+
+This means that even if a dynamic mechanism were to be adopted, new environment
+markers would likely still need to be spelled out in a PEP.
+
+Second, the introduction of a dynamic mechanism would require a more complex
+implementation in the packaging library, which would be a significant departure
+from the current approach.
+
+Having said that, the new ``sys.abi_features`` attribute provides a natural
+extension point for any new ABI features, even if specific to a subset of
+interpreters, should the need arise to add such new features with a subsequent
+PEP.
+
+Open Issues
+===========
+
+Other Environment Markers
+-------------------------
+If other environment markers are needed right now, this PEP could be extended
+to include them.
+
+Other Tooling
+-------------
+The reference implementation is based on the ``packaging`` library and ``pip``.
+We have confirmed that this allows for building and installing packages with
+several build backends.
+It is possible that other tools should be added to the reference
+implementation.
+
+
+Footnotes
+=========
+
+.. [#python-free-threading] Python experimental support for free threading
+   is available in Python 3.13 and later. For more information, see `Python
+   experimental support for free threading`_.
+
+.. [#bitness] While there are some related environment markers available, such
+   as ``platform_machine`` and ``platform_python_implementation``, these are
+   not sufficient to reliably determine the bitness of the interpreter,
+   particularly on platforms that allow the execution of either kind of binary.
+
+.. [#sys-abi-features] This is contingent on the availability of the
+   ``sys.abi_features`` attribute in the Python standard library. In
+   versions that don't provide this attribute, the marker will be constructed
+   from other available information, such as the ``sys.abiflags`` string.
+
+
+.. _Python experimental support for free threading: https://docs.python.org/3/howto/free-threading-python.html
+.. _Python free-threading guide: https://py-free-threading.github.io/
+.. _Environment marker for free-threading: https://discuss.python.org/t/environment-marker-for-free-threading/60007
+.. _Compatibility Status Tracking: https://py-free-threading.github.io/tracking/
+.. _Free-Treaded Wheels: https://hugovk.github.io/free-threaded-wheels/
+.. _the PEP 703 acceptance post: https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075
+
+Acknowledgements
+================
+
+Thanks to Filipe Laíns for the suggestion of the ``abi_features`` attribute
+and to Stephen Rosen for the Backwards Compatibility section of :pep:`735`,
+which served as a template for the corresponding section in this PEP.
+
+Copyright
+=========
+
+This document is placed in the public domain or under the
+CC0-1.0-Universal license, whichever is more permissive.


Reviews:
user: login: AA-Turner
body: Initial comments. Review comments will get lost when you rename the file, so I've not done a review of anything except the headers yet.

A
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-03-21T14:38:11Z
user: login: JelleZijlstra
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T14:46:05Z
user: login: zklaus
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-21T16:44:52Z
user: login: zklaus
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-21T16:45:24Z
user: login: AA-Turner
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T17:41:35Z
user: login: pfmoore
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T17:55:13Z
user: login: pfmoore
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T17:59:49Z
user: login: JelleZijlstra
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T18:53:47Z
user: login: pfmoore
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T19:00:33Z
user: login: AA-Turner
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T19:22:22Z
user: login: AA-Turner
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-21T19:23:53Z
user: login: zklaus
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-24T09:54:54Z
user: login: zklaus
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-24T09:59:25Z
user: login: zklaus
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-24T14:28:15Z
user: login: zklaus
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-24T14:30:12Z
user: login: konstin
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-24T15:08:29Z
user: login: pfmoore
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-24T15:27:05Z
user: login: konstin
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-24T19:26:04Z
user: login: AA-Turner
body: A few final editorial comments (prefixed as such) and two remaining questions -- but these could be taken to the Discourse thread, so don't let it block getting the PR merged.

Thank you!

A
state: APPROVED
author_association: MEMBER
submitted_at: 2025-03-24T21:19:24Z
user: login: zklaus
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-25T10:03:44Z
user: login: zklaus
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-25T11:02:35Z
user: login: XuehaiPan
state: COMMENTED
author_association: NONE
submitted_at: 2025-03-25T19:51:33Z
user: login: rgommers
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-25T19:56:51Z
user: login: AA-Turner
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-25T20:06:14Z
user: login: XuehaiPan
state: COMMENTED
author_association: NONE
submitted_at: 2025-03-25T20:06:14Z
user: login: AA-Turner
state: APPROVED
author_association: MEMBER
submitted_at: 2025-03-25T20:10:09Z
user: login: rgommers
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-26T13:25:35Z

Review comments:
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 790
path: peps/pep-0790.rst
user: login: AA-Turner
body: Please use the next free number, 780
```suggestion
PEP: 780
```
created_at: 2025-03-21T14:34:48Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 790
+Title: New environment markers for modern Python environments
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
path: peps/pep-0790.rst
user: login: AA-Turner
body: @lysnikolaou can you confirm sponsorship?
created_at: 2025-03-21T14:34:50Z
author_association: MEMBER
path: peps/pep-0790.rst
user: login: AA-Turner
body: The file will also need renaming to 780
created_at: 2025-03-21T14:35:03Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 790
+Title: New environment markers for modern Python environments
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/environment-marker-for-free-threading/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Feb-2025
path: peps/pep-0790.rst
user: login: AA-Turner
body: Creation date is when the PEP number is assigned
```suggestion
Created: 21-Mar-2025
```
created_at: 2025-03-21T14:35:29Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 790
+Title: New environment markers for modern Python environments
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/environment-marker-for-free-threading/60007
path: peps/pep-0790.rst
user: login: AA-Turner
body: Use the short links -- but I would instead put this existing discussion in Post-History, and leave Discussions-To empty until this PR is merged (then you will open a new discussion thread).
```suggestion
Discussions-To: https://discuss.python.org/t/60007
```
created_at: 2025-03-21T14:36:32Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 790
+Title: New environment markers for modern Python environments
path: peps/pep-0790.rst
user: login: AA-Turner
body: Minor: "modern" always ages poorly, as this PEP will still exist in twenty years yet will certainly not be modern any more. Is there a better term we can use?
created_at: 2025-03-21T14:37:24Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 790
+Title: New environment markers for modern Python environments
path: peps/pep-0790.rst
user: login: JelleZijlstra
body: Suggestion: "ABI features as environment markers"
created_at: 2025-03-21T14:46:05Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 790
+Title: New environment markers for modern Python environments
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
path: peps/pep-0790.rst
user: login: zklaus
body: See https://github.com/python/peps/pull/4315#issuecomment-2743569002
created_at: 2025-03-21T16:44:51Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 790
+Title: New environment markers for modern Python environments
path: peps/pep-0790.rst
user: login: zklaus
body: So true! Done.
created_at: 2025-03-21T16:45:24Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
path: peps/pep-0780.rst
user: login: AA-Turner
body: ```suggestion
Python-Version: 3.14
Post-History:
  `5 Aug 2024 <https://discuss.python.org/t/60007>`__,
```
created_at: 2025-03-21T17:07:55Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
path: peps/pep-0780.rst
user: login: AA-Turner
body: As previously suggested, leaving out Discussions-To for now (until the PR is merged, per the checklist)
```suggestion
```
created_at: 2025-03-21T17:08:38Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
path: peps/pep-0780.rst
user: login: AA-Turner
body: @pfmoore question from a governance perspective, as PEP-0776 is to be split into two parts (packaging & non-packaging). Do you have similar thoughts here? The PEP proposes both a new `sys.abi_features` attribute and a new `sys_abi_features` environment marker.
created_at: 2025-03-21T17:12:18Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
path: peps/pep-0780.rst
user: login: AA-Turner
body: ```suggestion
    If accepted, the contents of this PEP should be integrated into the
```
created_at: 2025-03-21T17:12:35Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
path: peps/pep-0780.rst
user: login: AA-Turner
body: ```suggestion
This PEP defines using ABI features as environment markers for project
dependencies, through a new ``sys_abi_features`` environment marker and
:data:`!sys.abi_features` attribute in the :mod:`sys` module.
```
created_at: 2025-03-21T17:16:08Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
path: peps/pep-0780.rst
user: login: AA-Turner
body: ```suggestion
new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
```
created_at: 2025-03-21T17:17:05Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
path: peps/pep-0780.rst
user: login: AA-Turner
body: I think this could be tightened up -- this PEP only proposes one new environment marker for ABI features. Perhaps (though you may want to rephrase):

```suggestion
In 2015, :pep:`508` established environment markers to specify dependencies
based on environment conditions.
The development of free-threaded CPython [#python-free-threading]_
has underlined the need for an environment marker to discriminate between
different ABI features that the interpreter was built with.
For example, currently there is
```


created_at: 2025-03-21T17:22:34Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
path: peps/pep-0780.rst
user: login: AA-Turner
body: ```suggestion
  failures and runtime crashes. It would be beneficial if the metadata
```
created_at: 2025-03-21T17:23:09Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
path: peps/pep-0780.rst
user: login: AA-Turner
body: ```suggestion
environment marker for free-threading will make that rollout significantly easier.
```
created_at: 2025-03-21T17:23:59Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
path: peps/pep-0780.rst
user: login: AA-Turner
body: I imagine this also applies to C++, Rust, etc
```suggestion
distinguish between the two may be relevant for packages that provide compiled
extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
```
created_at: 2025-03-21T17:24:33Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
path: peps/pep-0780.rst
user: login: AA-Turner
body: The second half of the sentence (after '-') doesn't make sense.
```suggestion
SciPy is an optional dependency only. In that case, it would be useful to be
able to specify that SciPy is required *unless* the interpreter is a 32-bit one
on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
from-source installations due to the missing wheels.
```
created_at: 2025-03-21T17:26:41Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has one mechanism to provide information
+about the ABI of the interpreter, namely the ``sys.abiflags`` attribute.
path: peps/pep-0780.rst
user: login: AA-Turner
body: Also `sysconfig`?
created_at: 2025-03-21T17:30:05Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has one mechanism to provide information
+about the ABI of the interpreter, namely the ``sys.abiflags`` attribute.
+This attribute is a string that contains a number of flags, such as ``d`` for
+debug builds, but it is not easily understood and not uniformly available.
+The new ``sys.abi_features`` attribute is both and is designed to be a superset
+of the information contained in ``sys.abiflags``, which is why we chose to
+include the ``debug`` feature.
path: peps/pep-0780.rst
user: login: AA-Turner
body: 'is both' what? I think it would be better to describe this as "there is already a mechanism X, we introduce a new attribute Y, Y can be used for everything X did and also new capability Z". Currently, the introduction of the attribute is not very well described (e.g. this section doesn't mention it is a frozenset, which attributes will it contain, what format (integer with bitflags, set of strings, enum), etc).
created_at: 2025-03-21T17:32:04Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has one mechanism to provide information
+about the ABI of the interpreter, namely the ``sys.abiflags`` attribute.
+This attribute is a string that contains a number of flags, such as ``d`` for
+debug builds, but it is not easily understood and not uniformly available.
+The new ``sys.abi_features`` attribute is both and is designed to be a superset
+of the information contained in ``sys.abiflags``, which is why we chose to
+include the ``debug`` feature.
+The established ``sys.abiflags`` also has a direct link to the naming of
+various filesystem paths. This can be convenient, but precludes its use for the
+documentation of important ABI features that are *not* intended to impact these
+paths.
+
+The new ``sys.abi_features`` attribute provides a place for this, and because
+it decouples the information from filesystem paths, it can offer significantly
+more clarity.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, which is the accepted proposal for free threading, states that the
path: peps/pep-0780.rst
user: login: AA-Turner
body: ```suggestion
:pep:`703`, the accepted proposal for free threading, states that the
```
created_at: 2025-03-21T17:35:37Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has one mechanism to provide information
+about the ABI of the interpreter, namely the ``sys.abiflags`` attribute.
+This attribute is a string that contains a number of flags, such as ``d`` for
+debug builds, but it is not easily understood and not uniformly available.
+The new ``sys.abi_features`` attribute is both and is designed to be a superset
+of the information contained in ``sys.abiflags``, which is why we chose to
+include the ``debug`` feature.
+The established ``sys.abiflags`` also has a direct link to the naming of
+various filesystem paths. This can be convenient, but precludes its use for the
+documentation of important ABI features that are *not* intended to impact these
+paths.
+
+The new ``sys.abi_features`` attribute provides a place for this, and because
+it decouples the information from filesystem paths, it can offer significantly
+more clarity.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, which is the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Teaser
+------
+
+To give an idea of the new environment marker, here is a simple example.
+For further examples, see the `Examples`_ section below.
+
+Dependencies can be marked as required for a free threading build of python
+using the following syntax::
+
+    cython>3.1.0b1; "free-threading" in sys_abi_features
+
+or, explicitly, for a gil-enabled build::
+
+    cython; "free-threading" not in sys_abi_features
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython >=3.13, but the bitness
path: peps/pep-0780.rst
user: login: AA-Turner
body: ```suggestion
GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
```
created_at: 2025-03-21T17:37:25Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has one mechanism to provide information
+about the ABI of the interpreter, namely the ``sys.abiflags`` attribute.
+This attribute is a string that contains a number of flags, such as ``d`` for
+debug builds, but it is not easily understood and not uniformly available.
+The new ``sys.abi_features`` attribute is both and is designed to be a superset
+of the information contained in ``sys.abiflags``, which is why we chose to
+include the ``debug`` feature.
+The established ``sys.abiflags`` also has a direct link to the naming of
+various filesystem paths. This can be convenient, but precludes its use for the
+documentation of important ABI features that are *not* intended to impact these
+paths.
+
+The new ``sys.abi_features`` attribute provides a place for this, and because
+it decouples the information from filesystem paths, it can offer significantly
+more clarity.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, which is the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Teaser
+------
path: peps/pep-0780.rst
user: login: AA-Turner
body: I'm not sure a "Teaser" section should be in the Specification
created_at: 2025-03-21T17:38:00Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has one mechanism to provide information
+about the ABI of the interpreter, namely the ``sys.abiflags`` attribute.
+This attribute is a string that contains a number of flags, such as ``d`` for
+debug builds, but it is not easily understood and not uniformly available.
+The new ``sys.abi_features`` attribute is both and is designed to be a superset
+of the information contained in ``sys.abiflags``, which is why we chose to
+include the ``debug`` feature.
+The established ``sys.abiflags`` also has a direct link to the naming of
+various filesystem paths. This can be convenient, but precludes its use for the
+documentation of important ABI features that are *not* intended to impact these
+paths.
+
+The new ``sys.abi_features`` attribute provides a place for this, and because
+it decouples the information from filesystem paths, it can offer significantly
+more clarity.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, which is the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Teaser
+------
+
+To give an idea of the new environment marker, here is a simple example.
+For further examples, see the `Examples`_ section below.
+
+Dependencies can be marked as required for a free threading build of python
+using the following syntax::
+
+    cython>3.1.0b1; "free-threading" in sys_abi_features
+
+or, explicitly, for a gil-enabled build::
+
+    cython; "free-threading" not in sys_abi_features
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython >=3.13, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
path: peps/pep-0780.rst
user: login: AA-Turner
body: What about other interpreters that have analogues to ``--with-pydebug``?
created_at: 2025-03-21T17:38:55Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
path: peps/pep-0780.rst
user: login: AA-Turner
body: Having read through the PEP, I think this subsection could probably be either (a) shortened or (b) merged into the Specification section and just have a sentence or two here describing how `abi_features` relates to `abiflags`.
created_at: 2025-03-21T17:40:48Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
path: peps/pep-0780.rst
user: login: pfmoore
body: Unfortunately, I think it does.

It may be possible to handle the new marker without a second PEP - I'd be willing to support adding `sys_abi_features` to the marker spec as a simple update to the specification. It would still need raising on the packaging Discourse, though. And there would be questions about how tools running under versions of Python without the new sys attribute should handle the marker, so it's not completely uncontroversial.
created_at: 2025-03-21T17:55:13Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
path: peps/pep-0780.rst
user: login: pfmoore
body: Looking at the PEP itself, I see that it introduces the idea of markers which are set objects. That's something that PEP 751 also introduces - the PEP authors here should probably look at PEP 751 (which is currently being reviewed for approval by me) to ensure they don't contradict what's being said there. I *think* it's compatible, but I haven't checked thoroughly.
created_at: 2025-03-21T17:59:49Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
path: peps/pep-0780.rst
user: login: JelleZijlstra
body: It might make sense to treat this only as a packaging PEP, since the changes to CPython itself seem small enough to be handled without a PEP. So the approval process would be a packaging PEP for the new markers, plus standard core dev consensus for the related CPython changes.
created_at: 2025-03-21T18:53:47Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
path: peps/pep-0780.rst
user: login: pfmoore
body: That's also a reasonable approach.

Taking the last few comments to their extreme, we could make the core change without a PEP, and agree the packaging spec change can be done without a PEP as well. I think that's probably going a bit too far, though 🙂
created_at: 2025-03-21T19:00:32Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,470 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `5 Aug 2024 <https://discuss.python.org/t/60007>`__,
path: peps/pep-0780.rst
user: login: AA-Turner
body: Bad suggestion, sorry
```suggestion
  `05 Aug 2024 <https://discuss.python.org/t/60007>`__,
```
created_at: 2025-03-21T19:22:22Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,470 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05 Aug 2024 <https://discuss.python.org/t/60007>`__,
path: peps/pep-0780.rst
user: login: AA-Turner
body: Attempt 3...
```suggestion
  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
```
created_at: 2025-03-21T19:23:53Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has one mechanism to provide information
+about the ABI of the interpreter, namely the ``sys.abiflags`` attribute.
+This attribute is a string that contains a number of flags, such as ``d`` for
+debug builds, but it is not easily understood and not uniformly available.
+The new ``sys.abi_features`` attribute is both and is designed to be a superset
+of the information contained in ``sys.abiflags``, which is why we chose to
+include the ``debug`` feature.
+The established ``sys.abiflags`` also has a direct link to the naming of
+various filesystem paths. This can be convenient, but precludes its use for the
+documentation of important ABI features that are *not* intended to impact these
+paths.
+
+The new ``sys.abi_features`` attribute provides a place for this, and because
+it decouples the information from filesystem paths, it can offer significantly
+more clarity.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, which is the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Teaser
+------
+
+To give an idea of the new environment marker, here is a simple example.
+For further examples, see the `Examples`_ section below.
+
+Dependencies can be marked as required for a free threading build of python
+using the following syntax::
+
+    cython>3.1.0b1; "free-threading" in sys_abi_features
+
+or, explicitly, for a gil-enabled build::
+
+    cython; "free-threading" not in sys_abi_features
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython >=3.13, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
path: peps/pep-0780.rst
user: login: zklaus
body: Initially, the intention was exactly to have this be more widely applicable, but the problem is that it is not clear what exactly would be guaranteed in general.

Is it just the addition of `sys.gettotalrefcounts()`? Perhaps also other Python API? Or maybe even some of the runtime checks mentioned in [the debug build documentation](https://docs.python.org/3/using/configure.html#python-debug-build)?

Limiting it to the debug builds of CPython keeps the correspondence with `"d" in sys.abiflags`, ensures that it's clear what to expect on CPython, and is clear in preventing other interpreters from creating potential confusion.
At the same time, it keeps open the possibility to later specify exactly what a debug build is in a more general manner and opening up the ABI feature to any interpreter that implements it at that time.
created_at: 2025-03-24T09:54:53Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has one mechanism to provide information
+about the ABI of the interpreter, namely the ``sys.abiflags`` attribute.
+This attribute is a string that contains a number of flags, such as ``d`` for
+debug builds, but it is not easily understood and not uniformly available.
+The new ``sys.abi_features`` attribute is both and is designed to be a superset
+of the information contained in ``sys.abiflags``, which is why we chose to
+include the ``debug`` feature.
+The established ``sys.abiflags`` also has a direct link to the naming of
+various filesystem paths. This can be convenient, but precludes its use for the
+documentation of important ABI features that are *not* intended to impact these
+paths.
+
+The new ``sys.abi_features`` attribute provides a place for this, and because
+it decouples the information from filesystem paths, it can offer significantly
+more clarity.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, which is the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Teaser
+------
path: peps/pep-0780.rst
user: login: zklaus
body: Agreed. With the more developed example section now, I think we can just remove this section here.
created_at: 2025-03-24T09:59:24Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
path: peps/pep-0780.rst
user: login: zklaus
body: I tried to address all three of your comments regarding this section by significantly shortening it, hopefully clearing up the relation to `sys.abiflags`.

What do you think?
created_at: 2025-03-24T14:28:15Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
path: peps/pep-0780.rst
user: login: zklaus
body: Thanks for the feedback, that makes sense!

Shall we then discuss this as a packaging PEP and once we have community agreement on names and content make the necessary additions to CPython?
created_at: 2025-03-24T14:30:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so.
+Hence, the `ABI Features`_ listed above are added to the Python standard
+library.
+
+Since they are all the result of compile time choices describing basic features
+of the interpreter, the most intuitive place to put them is in ``sys``.
+Since there is no intrinsic order, nor a possibility for duplication, they are
+added as a ``frozenset`` of strings.
+
+All Python interpreters MUST provide the ``sys.abi_features`` attribute as a
+``frozenset`` of strings, which MUST contain only the `ABI Features`_ that are
+defined in this PEP or in a subsequent PEP.
+
+An example value would be ``sys.abi_features == frozenset({"free-threading",
+"debug", "32-bit"})`` on a free-threaded debug build for win32.
+
+Environment Markers
+'''''''''''''''''''
+
+To make ABI features available in dependency specifications, a new environment
+marker variable, ``sys_abi_features``, is added to the format of dependency
+specifiers with the same semantics as the ``sys.abi_features`` attribute
+proposed above.
+
+To do this, we need to extend the grammar laid out in :pep:`508` and maintained
+in the :ref:`packaging:dependency-specifiers` and document the possible values.
+
+The grammar is extended to include the ``sys_abi_features`` marker variable by
+augmenting the definition of ``env_var`` as follows::
+
+    env_var       = ('python_version' | 'python_full_version' |
+                     'os_name' | 'sys_platform' | 'platform_release' |
+                     'platform_system' | 'platform_version' |
+                     'platform_machine' | 'platform_python_implementation' |
+                     'implementation_name' | 'implementation_version' |
+                     'sys_abi_features' |
+                     'extra' # ONLY when defined by a containing layer
+                     )
+
+Like the grammar, also the overview table of environment markers in
+:ref:`packaging:dependency-specifiers` is augmented to add the following row:
+
+.. list-table::
+    :header-rows: 1
+
+    * - Marker
+      - Python equivalent
+      - Sample values
+    * - ``sys_abi_features``
+      - ``sys.abi_features`` [#sys-abi-features]_
+      - ``set()``, ``{"free-threading"}``, ``{"free-threading", "debug"}``
+
+With these additions, ABI features can be used in dependency specifications via
+the ``in`` operator to test for the presence of a feature, or the ``not in``
+operator to test for the absence of a feature.
path: peps/pep-0780.rst
user: login: konstin
body: Could you add a sentence about how bad comparisons such as `"3.10.0" < "sys_abi_features"` should be treated? (As someone who has to support such checks already for other environment markers such as `extra`, I'd prefer to both allow to both error and allow to evaluate to false, at the implementations choice)
created_at: 2025-03-24T15:08:29Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so.
+Hence, the `ABI Features`_ listed above are added to the Python standard
+library.
+
+Since they are all the result of compile time choices describing basic features
+of the interpreter, the most intuitive place to put them is in ``sys``.
+Since there is no intrinsic order, nor a possibility for duplication, they are
+added as a ``frozenset`` of strings.
+
+All Python interpreters MUST provide the ``sys.abi_features`` attribute as a
+``frozenset`` of strings, which MUST contain only the `ABI Features`_ that are
+defined in this PEP or in a subsequent PEP.
+
+An example value would be ``sys.abi_features == frozenset({"free-threading",
+"debug", "32-bit"})`` on a free-threaded debug build for win32.
+
+Environment Markers
+'''''''''''''''''''
+
+To make ABI features available in dependency specifications, a new environment
+marker variable, ``sys_abi_features``, is added to the format of dependency
+specifiers with the same semantics as the ``sys.abi_features`` attribute
+proposed above.
+
+To do this, we need to extend the grammar laid out in :pep:`508` and maintained
+in the :ref:`packaging:dependency-specifiers` and document the possible values.
+
+The grammar is extended to include the ``sys_abi_features`` marker variable by
+augmenting the definition of ``env_var`` as follows::
+
+    env_var       = ('python_version' | 'python_full_version' |
+                     'os_name' | 'sys_platform' | 'platform_release' |
+                     'platform_system' | 'platform_version' |
+                     'platform_machine' | 'platform_python_implementation' |
+                     'implementation_name' | 'implementation_version' |
+                     'sys_abi_features' |
+                     'extra' # ONLY when defined by a containing layer
+                     )
+
+Like the grammar, also the overview table of environment markers in
+:ref:`packaging:dependency-specifiers` is augmented to add the following row:
+
+.. list-table::
+    :header-rows: 1
+
+    * - Marker
+      - Python equivalent
+      - Sample values
+    * - ``sys_abi_features``
+      - ``sys.abi_features`` [#sys-abi-features]_
+      - ``set()``, ``{"free-threading"}``, ``{"free-threading", "debug"}``
+
+With these additions, ABI features can be used in dependency specifications via
+the ``in`` operator to test for the presence of a feature, or the ``not in``
+operator to test for the absence of a feature.
path: peps/pep-0780.rst
user: login: pfmoore
body: You should assume the semantics for set-valued markers [as described in PEP 751](https://peps.python.org/pep-0751/#additions-to-marker-expression-syntax). That PEP has been submitted for approval and while I haven't made a decision on it yet, I can confirm that assuming it *does* get accepted, it will be with the semantics described there.

The specific example you give, `"3.10.0" < sys_abi_features` (corrected to remove the presumably unintended quotes) will (according to that spec) be treated as having the Python behaviour, which is to raise a TypeError ("<" not supported between instances of str and set).

I will note that there's no place in the current marker spec that allows the implementation to choose the evaluation rule, and I don't think we should introduce such behaviour.
created_at: 2025-03-24T15:27:04Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so.
+Hence, the `ABI Features`_ listed above are added to the Python standard
+library.
+
+Since they are all the result of compile time choices describing basic features
+of the interpreter, the most intuitive place to put them is in ``sys``.
+Since there is no intrinsic order, nor a possibility for duplication, they are
+added as a ``frozenset`` of strings.
+
+All Python interpreters MUST provide the ``sys.abi_features`` attribute as a
+``frozenset`` of strings, which MUST contain only the `ABI Features`_ that are
+defined in this PEP or in a subsequent PEP.
+
+An example value would be ``sys.abi_features == frozenset({"free-threading",
+"debug", "32-bit"})`` on a free-threaded debug build for win32.
+
+Environment Markers
+'''''''''''''''''''
+
+To make ABI features available in dependency specifications, a new environment
+marker variable, ``sys_abi_features``, is added to the format of dependency
+specifiers with the same semantics as the ``sys.abi_features`` attribute
+proposed above.
+
+To do this, we need to extend the grammar laid out in :pep:`508` and maintained
+in the :ref:`packaging:dependency-specifiers` and document the possible values.
+
+The grammar is extended to include the ``sys_abi_features`` marker variable by
+augmenting the definition of ``env_var`` as follows::
+
+    env_var       = ('python_version' | 'python_full_version' |
+                     'os_name' | 'sys_platform' | 'platform_release' |
+                     'platform_system' | 'platform_version' |
+                     'platform_machine' | 'platform_python_implementation' |
+                     'implementation_name' | 'implementation_version' |
+                     'sys_abi_features' |
+                     'extra' # ONLY when defined by a containing layer
+                     )
+
+Like the grammar, also the overview table of environment markers in
+:ref:`packaging:dependency-specifiers` is augmented to add the following row:
+
+.. list-table::
+    :header-rows: 1
+
+    * - Marker
+      - Python equivalent
+      - Sample values
+    * - ``sys_abi_features``
+      - ``sys.abi_features`` [#sys-abi-features]_
+      - ``set()``, ``{"free-threading"}``, ``{"free-threading", "debug"}``
+
+With these additions, ABI features can be used in dependency specifications via
+the ``in`` operator to test for the presence of a feature, or the ``not in``
+operator to test for the absence of a feature.
path: peps/pep-0780.rst
user: login: konstin
body: I'm happy if we agree that the marker introduced by this PEP uses the same semantics for set-based markers as defined by PEP 751.
created_at: 2025-03-24T19:26:04Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
path: peps/pep-0780.rst
user: login: AA-Turner
body: Editorial: Unclear why this is a third-level heading
```suggestion
ABI Features
------------
```
created_at: 2025-03-24T20:59:09Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
path: peps/pep-0780.rst
user: login: AA-Turner
body: Editorial: Again we can be clearer on what is changing in the section title
```suggestion
The :data:`!sys.abi_features` attribute
---------------------------------------
```
created_at: 2025-03-24T20:59:40Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so.
+Hence, the `ABI Features`_ listed above are added to the Python standard
+library.
+
+Since they are all the result of compile time choices describing basic features
+of the interpreter, the most intuitive place to put them is in ``sys``.
+Since there is no intrinsic order, nor a possibility for duplication, they are
+added as a ``frozenset`` of strings.
+
+All Python interpreters MUST provide the ``sys.abi_features`` attribute as a
+``frozenset`` of strings, which MUST contain only the `ABI Features`_ that are
+defined in this PEP or in a subsequent PEP.
+
+An example value would be ``sys.abi_features == frozenset({"free-threading",
+"debug", "32-bit"})`` on a free-threaded debug build for win32.
+
+Environment Markers
+'''''''''''''''''''
path: peps/pep-0780.rst
user: login: AA-Turner
body: Editorial: likewise
```suggestion
``sys_abi_features`` environment marker
---------------------------------------
```
created_at: 2025-03-24T21:01:49Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
path: peps/pep-0780.rst
user: login: AA-Turner
body: I'm unclear on the rationale for having bitness be optional, especially given the motivating example of replacing `sys.maxsize`.

Do these values work for e.g. MicroPython?
created_at: 2025-03-24T21:07:32Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
path: peps/pep-0780.rst
user: login: AA-Turner
body: Editorial: I don't think this subsection adds much, the first paragraph is covered above (in *Rationale* & *Motivation*) and the second paragraph is covered below (in the remainder of *Specification*).
created_at: 2025-03-24T21:11:47Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so.
+Hence, the `ABI Features`_ listed above are added to the Python standard
+library.
+
+Since they are all the result of compile time choices describing basic features
+of the interpreter, the most intuitive place to put them is in ``sys``.
+Since there is no intrinsic order, nor a possibility for duplication, they are
+added as a ``frozenset`` of strings.
+
+All Python interpreters MUST provide the ``sys.abi_features`` attribute as a
+``frozenset`` of strings, which MUST contain only the `ABI Features`_ that are
+defined in this PEP or in a subsequent PEP.
+
+An example value would be ``sys.abi_features == frozenset({"free-threading",
+"debug", "32-bit"})`` on a free-threaded debug build for win32.
+
+Environment Markers
+'''''''''''''''''''
+
+To make ABI features available in dependency specifications, a new environment
+marker variable, ``sys_abi_features``, is added to the format of dependency
+specifiers with the same semantics as the ``sys.abi_features`` attribute
+proposed above.
+
+To do this, we need to extend the grammar laid out in :pep:`508` and maintained
+in the :ref:`packaging:dependency-specifiers` and document the possible values.
+
+The grammar is extended to include the ``sys_abi_features`` marker variable by
+augmenting the definition of ``env_var`` as follows::
+
+    env_var       = ('python_version' | 'python_full_version' |
+                     'os_name' | 'sys_platform' | 'platform_release' |
+                     'platform_system' | 'platform_version' |
+                     'platform_machine' | 'platform_python_implementation' |
+                     'implementation_name' | 'implementation_version' |
+                     'sys_abi_features' |
+                     'extra' # ONLY when defined by a containing layer
+                     )
+
+Like the grammar, also the overview table of environment markers in
+:ref:`packaging:dependency-specifiers` is augmented to add the following row:
+
+.. list-table::
+    :header-rows: 1
+
+    * - Marker
+      - Python equivalent
+      - Sample values
+    * - ``sys_abi_features``
+      - ``sys.abi_features`` [#sys-abi-features]_
+      - ``set()``, ``{"free-threading"}``, ``{"free-threading", "debug"}``
+
+With these additions, ABI features can be used in dependency specifications via
+the ``in`` operator to test for the presence of a feature, or the ``not in``
+operator to test for the absence of a feature.
+
+Note that the presence of ``sys.abi_features`` in the Python standard library
+makes implementation particularly easy for new Python versions, but its absence
+in older versions does not prevent the implementation of the new environment
+markers, as demonstrated in the `Reference Implementation`_.
+
+Examples
+========
+
+Require Cython Pre-release for Free-Threaded Python
+----------------------------------------------------
+To require a pre-release of Cython only for a free-threaded Python
+interpreter, the following dependency specification can be used::
+
+    cython >3.1.0a1; "free-threading" in sys_abi_features
+    cython ==3.0.*; "free-threading" not in sys_abi_features
+
+Require SciPy Unless on 32-bit ``win32``
+----------------------------------------
+To require SciPy unless on a 32-bit interpreter on Windows, the following
+dependency specification can be used::
+
+    scipy; platform_system != "Windows" or "32-bit" not in sys_abi_features
+
+Require NumPy for a Free-Threaded Interpreter With Debugging Capabilities
+--------------------------------------------------------------------------
+To require NumPy only for a free-threaded interpreter with debugging
+capabilities, the following dependency can be used::
+
+    numpy; "free-threading" in sys_abi_features and "debug" in sys_abi_features
+
+Backwards Compatibility
+=======================
+
+This is a pure extension to the existing environment markers and does not
+affect existing environment markers or dependency specifications, hence there
+are no direct backwards compatibility concerns.
+
+However, the introduction of the feature has implications for a
+number of ecosystem tools, especially those which attempt to support
+examination of data in ``pyproject.toml`` and ``requirements.txt``.
+
+Audit and Update Tools
+----------------------
+
+A wide range of tools understand Python dependency data as expressed in
+``requirements.txt`` files. (e.g., Dependabot, Tidelift, etc)
+
+Such tools inspect dependency data and, in some cases, offer tool-assisted or
+fully automated updates.
+It is our expectation that no such tools would support the new environment
+markers at first, and broad ecosystem support could take many months or even
+some number of years to arrive.
+
+As a result, users of the new environment markers would experience a
+degradation in their workflows and tool support at the time that they start
+using them. This is true of any new standard for where and how dependency data
+are encoded.
+
+Security Implications
+=====================
+
+This PEP introduces new syntax for specifying dependency information in
+projects. However, it does not introduce newly specified mechanisms for
+handling or resolving dependencies.
+
+It therefore does not carry security concerns other than those inherent in any
+tools which may already be used to install dependencies---i.e. malicious
+dependencies may be specified here, just as they may be specified in
+``requirements.txt`` files.
+
+How to Teach This
+=================
+
+The use of environment markers is well established and communicated chiefly
+in :ref:`packaging:dependency-specifiers`.
+The new environment marker can be introduced in the same document.
+Additionally, both for package authors and users, free-threading specific
+guidance can be provided at the `Python free-threading guide`_.
+The new ``sys.abi_features`` attribute will be documented in the Python
+standard library documentation.
+
+
+Reference Implementation
+========================
+
+The reference implementation for the ``sys.abi_features`` attribute can be
+found in `Add abi_features to sys
+<https://github.com/zklaus/cpython/pull/1>`__.
+
+The reference implementation for the environment markers is available in a fork
+of the ``packaging`` library at `Environment markers for ABI features
+<https://github.com/zklaus/packaging/pull/1>`__.
+
+`A demonstration package <https://github.com/zklaus/env-marker-example>`__ is
+also available.
+
+Since ``pip`` uses a vendored copy of ``packaging`` internally, we also provide
+`a patched version of pip
+<https://github.com/zklaus/pip/tree/env-marker-free-threading>`__, which is
+based on pypa/pip:main with the vendored ``packaging`` replaced by the
+reference implementation linked above.
path: peps/pep-0780.rst
user: login: AA-Turner
body: Editorial:
```suggestion
Since ``pip`` uses a vendored copy of ``packaging`` internally, we also provide
`a patched version of pip`__, which replaces the vendored ``packaging`` with the
reference implementation linked above.

__ https://github.com/zklaus/pip/tree/env-marker-free-threading
```
created_at: 2025-03-24T21:14:48Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so.
+Hence, the `ABI Features`_ listed above are added to the Python standard
+library.
+
+Since they are all the result of compile time choices describing basic features
+of the interpreter, the most intuitive place to put them is in ``sys``.
+Since there is no intrinsic order, nor a possibility for duplication, they are
+added as a ``frozenset`` of strings.
+
+All Python interpreters MUST provide the ``sys.abi_features`` attribute as a
+``frozenset`` of strings, which MUST contain only the `ABI Features`_ that are
+defined in this PEP or in a subsequent PEP.
+
+An example value would be ``sys.abi_features == frozenset({"free-threading",
+"debug", "32-bit"})`` on a free-threaded debug build for win32.
+
+Environment Markers
+'''''''''''''''''''
+
+To make ABI features available in dependency specifications, a new environment
+marker variable, ``sys_abi_features``, is added to the format of dependency
+specifiers with the same semantics as the ``sys.abi_features`` attribute
+proposed above.
+
+To do this, we need to extend the grammar laid out in :pep:`508` and maintained
+in the :ref:`packaging:dependency-specifiers` and document the possible values.
+
+The grammar is extended to include the ``sys_abi_features`` marker variable by
+augmenting the definition of ``env_var`` as follows::
+
+    env_var       = ('python_version' | 'python_full_version' |
+                     'os_name' | 'sys_platform' | 'platform_release' |
+                     'platform_system' | 'platform_version' |
+                     'platform_machine' | 'platform_python_implementation' |
+                     'implementation_name' | 'implementation_version' |
+                     'sys_abi_features' |
+                     'extra' # ONLY when defined by a containing layer
+                     )
+
+Like the grammar, also the overview table of environment markers in
+:ref:`packaging:dependency-specifiers` is augmented to add the following row:
+
+.. list-table::
+    :header-rows: 1
+
+    * - Marker
+      - Python equivalent
+      - Sample values
+    * - ``sys_abi_features``
+      - ``sys.abi_features`` [#sys-abi-features]_
+      - ``set()``, ``{"free-threading"}``, ``{"free-threading", "debug"}``
path: peps/pep-0780.rst
user: login: AA-Turner
body: Editorial: 
```suggestion
      - ``frozenset()``, ``frozenset({'free-threading', '64-bit'})``,
        ``frozenset({'gil-enabled', 'debug', '32-bit'})``
```
created_at: 2025-03-24T21:16:21Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so.
path: peps/pep-0780.rst
user: login: AA-Turner
body: Is it worth mentioning somewhere that e.g. `sys.abiflags` doesn't exist on Windows, but `sys.abi_features` will exist on every supported platform?
created_at: 2025-03-24T21:17:49Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+
+..
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines new environment markers for project dependencies.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute ``sys.abi_features``, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+:pep:`508` established environment markers to specify dependencies based on
+environment conditions. Since its adoption in 2015, the Python ecosystem has
+evolved and new features warrant their own environment markers.
+
+The primary motivation for extending the allowed set of environment markers now
+is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be quite beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly less
+bumpy.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
path: peps/pep-0780.rst
user: login: AA-Turner
body: I like the new wording, thank you!
created_at: 2025-03-24T21:18:38Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
path: peps/pep-0780.rst
user: login: zklaus
body: We are not aware of other needed values, certainly not in CPython. MicroPython is an interesting case, as it [supports some 16-bit platforms](https://github.com/micropython/micropython?tab=readme-ov-file#supported-platforms--architectures). It's reasonable to assume such an interpreter would need `16-bit`, but I'm not sure.

So overall, keeping it optional is meant to provide room for exotic interpreters, but it may be reasonable to tighten it down and rather ask maintainers of such interpreters to come forward with required additions.
I guess that is reason enough to have this discussion with the wider community.
created_at: 2025-03-25T10:03:44Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,447 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
+This PEP extends the environment markers to allow specifying dependencies
+based on specific ABI features of the Python interpreter.
+For this, it defines a set of `ABI Features`_ and specifies how they are made
+available via an `Addition to the Python Standard Library`_ in the form of a
+new attribute :data:`!sys.abi_features`, as well as for `Environment Markers`_ as a
+new marker variable, ``sys_abi_features``.
+
+Motivation
+==========
+
+In 2015, :pep:`508` established environment markers to specify dependencies
+based on environment conditions.
+The development of free-threaded CPython [#python-free-threading]_
+has underlined the need for an environment marker to discriminate between
+different ABI features that the interpreter was built with.
+For example, currently there is
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
+
+Some concrete examples of such issues have been discussed in the `Environment
+marker for free-threading`_ Discourse thread:
+
+- Cython has (experimental) support for free-threading only in its master
+  branch, and is used by a lot of projects that already publish ``cp313t``
+  wheels. Picking up the wrong Cython version is causing a lot of obscure build
+  failures and runtime crashes. It would be beneficial if the metadata
+  could express that (c.f. `Require Cython Pre-release for Free-Threaded
+  Python`_).
+- CFFI has no support for free-threading yet, and `Armin Rigo, one of the
+  maintainers, has stated
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
+
+While these concrete examples may be addressed later this year by Cython and
+CFFI making compatible releases, the same issue is going to repeat further up
+the stack. The free-threading rollout is expected to take several years, and an
+environment marker for free-threading will make that rollout significantly easier.
+
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide compiled
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_), to avoid failed
+from-source installations due to the missing wheels.
+
+
+Rationale
+=========
+
+The intention of this PEP is to introduce its core features with minimal impact
+on the existing ecosystem.
+The existing grammar proposed in :pep:`508` lends itself to a straightforward
+extension to include the new environment marker.
+
+Adding ``sys.abi_features`` to the Python Standard Library
+----------------------------------------------------------
+
+The Python standard library already has mechanisms to provide information about
+the ABI of the interpreter, like the :data:`!sys.abiflags` attribute and the
+:mod:`sysconfig` module, but these do not provide all the `ABI Features`_ that
+are relevant for environment markers.
+The new attribute :data:`!sys.abi_features` is a natural extension to the
+existing mechanisms, and it is a simple and intuitive way to provide this
+information, including the information from :data:`!sys.abiflags`.
+
+A Forward Looking View on Free-Threaded Python
+----------------------------------------------
+
+:pep:`703`, the accepted proposal for free threading, states that the
+rollout of free-threaded Python should be gradual, which has been clarified
+by the Python Steering Council in `the PEP 703 acceptance post`_ to mean a
+three stage process over multiple releases. It is therefore important to make
+sure that the mechanisms in this PEP are useable for Python interpreters where
+either free-threading or non-free-threading could be the default or the only
+option.
+
+At the time of writing, free-threaded Python is in Phase I: experimental phase.
+In this phase, there is an acute need for the proposed environment markers to
+help with the transition to free-threaded Python as package authors gradually
+add support.
+
+As the number of packages with support increases, and particularly during
+Phase II: Supported-but-not-default phase, we still anticipate a strong need
+for the environment markers to help with the transition.
+
+As free-threaded Python enters into Phase III: Default phase, the need for
+the environment markers will decrease, though at this point it is not clear
+that the GIL-enabled Python will be completely phased out (it may remain
+available as a non standard build option). If it persists, the inverse need for
+the ABI feature detection may arise.
+
+Indeed, in all three phases it may be necessary for package authors to choose
+specific versions of their dependencies based on the ABI features, with a shift
+from GIL-enabled as default to free-threading as default over time.
+
+The ABI features are designed with this in mind to guarantee usefulness and
+simplicity for the foreseeable future in a changing Python ecosystem.
+
+Specification
+=============
+
+The keywords "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**",
+"**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**",
+and "**OPTIONAL**"" in this document are to be interpreted as described in
+:rfc:`RFC 2119 <2119>`.
+
+Concepts
+--------
+
+ABI features are a clear description of certain properties of the Python
+interpreter. While some of these features can be queried already today, they
+are not easily nor uniformly accessible.
+
+Hence, the proposed feature MUST be made available via the Python standard
+library as ``sys.abi_features``, and as the new environment marker variable
+``sys_abi_features``.
+
+ABI Features
+''''''''''''
+
+ABI features are intrinsic properties of the Python interpreter, expressed as
+simple, understandable strings.
+However, not all features are equally applicable to all Python interpreters or
+Python versions. For example, the distinction between free-threaded and
+GIL-enabled interpreters is only relevant for CPython 3.13 onwards, but the bitness
+of the interpreter is relevant for all interpreters.
+
+All interpreters MUST handle the following ABI features as stated.
+ABI features that are restricted to particular interpreters MUST NOT be
+provided by other interpreters.
+The features are subdivided into groups and for each group there MUST be
+exactly one feature present, except when the group is marked as optional, in
+which case there MUST be at most one feature present.
+
+``free-threading`` or ``gil-enabled`` (only CPython)
+    If the Python interpreter is free-threaded, the ``free-threading`` feature
+    MUST be present and the ``gil-enabled`` feature MUST NOT be present.
+    Otherwise, the ``gil-enabled`` feature MUST be present and the
+    ``free-threading`` feature MUST NOT be present.
+
+``debug`` (only CPython, optional)
+    This ABI feature is reserved for the ``--with-pydebug`` build of CPython.
+    If the interpreter is a CPython interpreter with ``Py_DEBUG`` capabilities,
+    the ``debug`` feature MUST be present.
+    On POSIX systems, this corresponds to ``"d" in sys.abiflags``.
+
+``32-bit`` or ``64-bit`` (optional)
+    The bitness of the interpreter, that is, whether it is a 32-bit or 64-bit
+    build [#bitness]_. If the bitness is unknown or neither 32-bit nor 64-bit,
+    this feature MUST NOT be present.
+
+
+Addition to the Python Standard Library
+'''''''''''''''''''''''''''''''''''''''
+
+Making the ABI features available in an easily accessible, expressive,
+standardized way is useful beyond the scope of environment markers.
+For example, ``"32-bit" in sys.abi_features`` is much more expressive than the
+current standard test of comparing ``sys.maxsize`` with  ``2**32``, which can
+be found more than ten thousand times on GitHub.
+If one wants to determine whether the interpreter is a debug build, there is
+currently no standardized, cross platform way to do so.
path: peps/pep-0780.rst
user: login: zklaus
body: I added a clause to that effect. Thanks!
created_at: 2025-03-25T11:02:35Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,451 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
path: peps/pep-0780.rst
user: login: XuehaiPan
body: For packaging purpose, we can reference how [`conda`](https://github.com/conda/conda) handles this: the [virtual packages](https://docs.conda.io/projects/conda/en/stable/user-guide/tasks/manage-virtual.html#managing-virtual-packages).

> ## Managing virtual packages
> 
> "Virtual" packages are injected into the conda solver to allow real packages to depend on features present on the system that cannot be managed directly by conda, like system driver versions or CPU features. Virtual packages are not real packages and not displayed by `conda list`. Instead `conda` runs a small bit of code to detect the presence or absence of the system feature that corresponds to the package. The currently supported list of virtual packages includes:
> 
> - `__cuda`: Maximum version of CUDA supported by the display driver.
> - `__osx`: OSX version if applicable.
> - `__glibc`: Version of glibc supported by the OS.
> - `__linux`: Available when running on Linux.
> - `__unix`: Available when running on OSX or Linux.
> - `__win`: Available when running on Win.
> - `__conda`: Version of conda that is being used for solving.
> 
> Other virtual packages will be added in future conda releases. These are denoted by a leading double-underscore in the package name.

IMO, the virtual package approach is better than the boolean markers (present or absent). The virtual package is more expressive:

```yaml
requirements:
  - __unix 0.0
  - __osx >= 15.0
  - __freethreading 0.0
```

```yaml
requirements:
  - __unix 0.0
  - __glibc >= 2.28
  - __freethreading 0.0
  - __cuda >= 12.8
```
created_at: 2025-03-25T19:51:32Z
author_association: NONE
diff_hunk: @@ -0,0 +1,451 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
path: peps/pep-0780.rst
user: login: rgommers
body: Let's not do that here please. That will only be confusing and potentially derail the discussion. We already have the marker syntax, that's what we need to work within. Conda's virtual packages are nice and in several ways more elegant than what Python packaging standards offer, but they're not really relevant to this PEP.
created_at: 2025-03-25T19:56:51Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,451 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
path: peps/pep-0780.rst
user: login: AA-Turner
body: @XuehaiPan please bring up this idea on the Discourse thread, once it is created.
created_at: 2025-03-25T20:06:13Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,451 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Status: Draft
+Type: Standards Track
+Topic: Packaging
+Created: 21-Mar-2025
+Python-Version: 3.14
+Post-History:
+  `05-Aug-2024 <https://discuss.python.org/t/60007>`__,
+
+..
+    If accepted, the contents of this PEP should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
+    .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
+
+Abstract
+========
+
+This PEP defines using ABI features as environment markers for project
+dependencies, through a new ``sys_abi_features`` environment marker and
+:data:`!sys.abi_features` attribute in the :mod:`sys` module.
+:pep:`508` (later moved to :ref:`packaging:dependency-specifiers`) introduced
+environment markers to specify dependencies based on rules that describe
+when the dependency should be used.
path: peps/pep-0780.rst
user: login: XuehaiPan
body: > We already have the marker syntax, that's what we need to work within.

Fair enough. I just want to point out how other package managers do for a similar purpose. :)
created_at: 2025-03-25T20:06:14Z
author_association: NONE
diff_hunk: @@ -0,0 +1,469 @@
+PEP: 780
+Title: ABI features as environment markers
+Author: Klaus Zimmermann <klaus_zimmermann@gmx.de>,
+        Ralf Gommers <ralf.gommers@gmail.com>
+Sponsor: Lysandros Nikolaou <lisandrosnik@gmail.com>
+Discussions-To: https://discuss.python.org/t/60007
+Status: Draft
+Type: Standards Track
+Topic: Packaging
path: peps/pep-0780.rst
user: login: rgommers
body: It'd be nice to unresolve this comment, since it was just brought up again on Discourse.
created_at: 2025-03-26T13:25:35Z
author_association: CONTRIBUTOR

PR comments:
user: login: ghost
created_at: 2025-03-21T12:34:25Z
body: All commit authors signed the Contributor License Agreement. <br/> [![CLA signed](https://cpython-clabot.herokuapp.com/cla-signed.svg)](https://cpython-clabot.herokuapp.com/signed-contributor-license-agreement?version=96a49432-b8b1-11ec-9bf5-bfe9ad6c72c4)
author_association: NONE
user: login: lysnikolaou
created_at: 2025-03-21T14:40:55Z
body: I've gone through the PEP a few times already. A first glance over the PR didn't reveal any obvious errors, so let's mark as ready for review.

I can also confirm I'll be the PEP sponsor for this.
author_association: MEMBER
user: login: JelleZijlstra
created_at: 2025-03-21T14:46:32Z
body: You'll also need to add an entry to the CODEOWNERS file. CODEOWNERS must have commit access to this repo, so it can be just Lys.
author_association: MEMBER
user: login: AA-Turner
created_at: 2025-03-25T19:46:55Z
body: @zklaus anything outstanding before merging?
author_association: MEMBER
user: login: zklaus
created_at: 2025-03-25T20:40:49Z
body: > @zklaus anything outstanding before merging?

No. I think this is ready.

Thanks for all the reviews everyone, @pfmoore, and particularly @AA-Turner! I really think it improved the PEP a lot!
author_association: CONTRIBUTOR
user: login: AA-Turner
created_at: 2025-03-25T20:42:46Z
body: @zklaus please now create a discussion thread for the PEP on [Discourse](https://discuss.python.org/c/peps/19), and then open a follow-up PR here to update Post-History and Discussions-To. The PEP has been rendered and is online at https://peps.python.org/pep-0780/.

Thank you!

A
author_association: MEMBER
user: login: zklaus
created_at: 2025-03-26T10:49:39Z
body: > @zklaus please now create a discussion thread for the PEP on [Discourse](https://discuss.python.org/c/peps/19), and then open a follow-up PR here to update Post-History and Discussions-To.

Done. The follow-up PR is #4324, the discussion is [here](https://discuss.python.org/t/86013).



author_association: CONTRIBUTOR