Build the readline module against libedit instead of GNU readline

[hmaarrfk]

I would really love to revive this effort.

I don't think many of the original objections were right, and now that uv has shipped with libedit support, i feel like there is a strong precedence for this.

I'm waiting on conda-forge/libedit-feedstock#15 to mark this PR as ready for review

Claude's write-up

This depends on conda-forge/libedit-feedstock#15. conda-forge's current libedit (3.1.20250104) re-sends signals with kill(0, signo), which signals the whole process group. With CPython on libedit, Ctrl-C then turns into an endless KeyboardInterrupt loop when python runs under another process such as uv run (astral-sh/uv#13919). #15 updates libedit to 20260512, which calls raise(signo) instead. This PR stays in draft until that update is merged and published.

Why reprioritize this now

#387 (open since 2020) asks for a way to use python without GPL-3 readline. Past discussion (#191, #192, #387, conda-forge/sqlite-feedstock#30) stalled because of concerns that libedit is "an incomplete readline clone". Since then, two major Python distributions have switched to libedit on Linux, not only macOS:

• uv / python-build-standalone builds its own libedit for Linux and macOS, "to avoid GPL licensing requirements of readline" (quirks).
• Homebrew passes --with-readline=editline unconditionally for python@3.11+ and depends on its own libedit on Linux (uses_from_macos "libedit", formula). The stated reason is licensing.
• The python.org macOS installers have always used libedit.

Since 3.13 the default interactive REPL is _pyrepl, which does its own line editing, history, completion and bracketed paste without readline or libedit (PEP 762). That reduces the user-visible risk.

GNU readline has also caused problems of its own here: conda-forge/readline-feedstock#35 was conda's libreadline.so.8 shadowing the system copy and breaking the system /bin/sh. libedit's library is libedit.so.0, so it can't clash like that.

Changes

• recipe/meta.yaml: readline → libedit in host, and in build when cross-compiling (unix only).
• recipe/build_base.sh: add --with-readline=editline.
• recipe/run_test.py: assert readline.backend == "editline". Without it, a configure fallback to GNU readline or to no readline module would pass the tests.
• Re-rendered; the readline pin drops out of .ci_support. libedit has no global pin, so its run_exports (>=3.1.x,<3.2) provides the bound.

This uses NetBSD libedit (conda-forge libedit, editline/readline.h, -ledit), which is what CPython's --with-readline=editline expects. It is not conda-forge's editline package, which is troglobit/editline. CPython doesn't support that one, and it lacks about 30 functions Modules/readline.c needs.

Local testing

• linux_64_build_typereleasechannel_targetsconda-forge_mainfreethreadingno built in docker with build-locally.py, against libedit 20250104.
• configure: checking how to link readline... edit.
• readline.cpython-315-x86_64-linux-gnu.so links libedit.so.0. The python package depends on libedit >=3.1.20250104,<3.2.0a0 and no longer on readline.
• All package tests passed, including the backend assert, plus the cython, setuptools, libpython and libpython-static tests.
• osx, the other linux arches, debug and freethreading builds have not been built locally.

Known behavior differences

These matter only when the readline backend is used: PYTHON_BASIC_REPL, input that isn't a terminal, input(), pdb/cmd, the sqlite3 CLI.

• libedit reads ~/.editrc, not ~/.inputrc. Third-party readline.parse_and_bind("tab: complete") silently does nothing; the stdlib's site, cmd, pdb and sqlite3 branch on readline.backend and handle it.
• The history file format differs (_HiStOrY_V2_ header, \040 escapes). Existing GNU-format ~/.python_history files are unreadable in the basic REPL. _pyrepl reads both formats.
• History truncation drops the libedit header, and libedit then can't read the file back (Python limited history test fails when configured to use editline instead of readline python/cpython#123018). The fix, gh-123018: Keep the libedit history file header when truncating python/cpython#157165, is merged to main and 3.14; the 3.15 backport ([3.15] gh-123018: Keep the libedit history file header when truncating (GH-157165) python/cpython#157172) is still open.
• Minor: a skipped set history-size test; get_begidx/get_endidx count characters instead of bytes for non-ASCII input; Ctrl-C in Ctrl-R search needs three presses (CTRL+C/KeyboardInterrupt in editline not working properly on macOS REPL python/cpython#100610).

TODO before leaving draft

• Update libedit to 3.1.20260512 (includes signal fix) libedit-feedstock#15 merged and published; rebuild against libedit 20260512.
• Carry gh-123018: Keep the libedit history file header when truncating python/cpython#157165 as a recipe patch until the 3.15 backport lands.
• Get green CI on osx. conda-forge has never shipped python with libedit on osx.
• Decide whether downstream packages that relied on python bringing in readline without declaring it need attention.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/35782722216. Examine the logs at this URL for more detail.}