Skip to content

[3006.x] Allow libyaml-linked PyYAML wheel in Linux onedir builds - #69950

Open
dwoz wants to merge 1 commit into
saltstack:3006.xfrom
dwoz:dwoz/fix/libyaml-onedir-3006x
Open

[3006.x] Allow libyaml-linked PyYAML wheel in Linux onedir builds#69950
dwoz wants to merge 1 commit into
saltstack:3006.xfrom
dwoz:dwoz/fix/libyaml-onedir-3006x

Conversation

@dwoz

@dwoz dwoz commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Backport of #69949 to 3006.x. The reporter's environment on #69907 was 3006.27, so this branch needs the same fix.

What does this PR do?

Adds pyyaml to the --only-binary allow-list for Linux onedir builds so pip installs PyYAML's manylinux2014 wheel (which bundles libyaml) instead of source-building it under the relenv toolchain.

Why

The Linux onedir build passes --no-binary=:all: to pip so every runtime dependency is compiled against the relenv toolchain. PyYAML's setup.py autodetects libyaml at compile time; because the relenv toolchain does not build or ship libyaml, the source build silently falls back to a pure-Python parser and the resulting onedir has no yaml.CSafeLoader and no _yaml*.so extension.

Salt's yamlloader uses getattr(yaml, "CSafeLoader", yaml.SafeLoader) so it does not crash, but every YAML load (configs, pillars, states, returners, mine, event bus) runs through the pure-Python parser, which is 10-20x slower. Users with segmented configs (many small pillar/state files) have reported salt-run salt.cmd test.ping taking ~20s where a libyaml-linked build completes in well under a second.

Reproduction

On any current 3006.27 or 3008.1 onedir install:

/opt/saltstack/salt/bin/python3 -c "import yaml; print(hasattr(yaml, 'CSafeLoader'))"
False

The reporter's workaround is:

/opt/saltstack/salt/bin/python3 -m pip install --force-reinstall --no-deps --only-binary :all: PyYAML==6.0.3

which pulls the manylinux wheel and restores CSafeLoader. This PR does the equivalent at build time so users get a libyaml-linked PyYAML out of the box.

Scope

Linux only. The Windows path does not use --no-binary=:all:, so pip already prefers the win_amd64 wheel (which bundles libyaml). macOS is unaffected for the same reason.

Licensing

LibYAML is MIT-licensed, matching PyYAML itself; bundling it via the manylinux wheel introduces no new license obligations. This mirrors the existing precedent for maturin, cassandra-driver, hatchling, cmake, ninja, and protobuf in the same allow-list.

Test plan

  • Reproduced on current 3006.27 onedir: hasattr(yaml, 'CSafeLoader') == False
  • Verified PyYAML 6.0.3 publishes cp3.10 through cp3.14 manylinux2014_x86_64 wheels
  • Build Source Packages CI must pass on this branch to confirm pip accepts the new allow-list entry and produces an onedir with _yaml*.so

Fixes #69907

The Linux onedir build passes ``--no-binary=:all:`` to pip so every
runtime dependency is compiled against the relenv toolchain and
linked against the vendored openssl/krb5/etc. PyYAML's setup.py
autodetects libyaml at compile time; because the relenv toolchain
does not build or ship libyaml, the source build silently falls
back to a pure-Python parser and the resulting onedir has no
``yaml.CSafeLoader`` and no ``_yaml.so`` extension.

Salt's ``yamlloader`` uses ``getattr(yaml, "CSafeLoader",
yaml.SafeLoader)`` so it does not crash, but every YAML load
(configs, pillars, states, returners, mine, event bus, etc.)
runs through the pure-Python parser, which is 10-20x slower.
Users with segmented configs have reported ``salt-run
salt.cmd test.ping`` taking ~20s where a libyaml-linked build
completes in well under a second.

Add ``pyyaml`` to the Linux ``--only-binary`` allow-list so pip
uses PyYAML's manylinux2014 wheel, which bundles libyaml
(MIT-licensed) and targets glibc 2.17+ (compatible with every
relenv Linux target). This mirrors the existing precedent for
``maturin``, ``cassandra-driver``, ``hatchling``, ``cmake``,
``ninja``, and ``protobuf``.

Fixes saltstack#69907
@dwoz
dwoz requested a review from a team as a code owner August 4, 2026 06:23
@dwoz dwoz added the test:full Run the full test suite label Aug 4, 2026
@dwoz dwoz added this to the Sulphur v3006.28 milestone Aug 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

test:full Run the full test suite

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants