Python: ensure disabled variants disabled corresponding build elements by johnwparent · Pull Request #7202 · spack/spack-packages

johnwparent · 2026-10-22T00:23:10Z

Previously multiple Python package variants could be enabled or disabled, the only change reflected in the build was the inclusion of CFLAGS and LDFLAGS.

This allowed python to find and link against system copies of dependencies required to build modules for which the corresponding variant was off, and build said module.
This produces modules with potential system references and allows python builds to diverge from the spec requirements.

This PR adds arguments to configure that disable the modules our variants configure to be off.

Also updates the python requirements pip expects. Pip unconditonally imports zlib and expat, so python must have both those modules

AI Disclosure: used claude opus 5.5 to explore all the gaps that needed covering, but initial triage, code, and mistakes are my own

Fixes #6903

Previously multiple Python package variants could be enabled or disabled, the only change reflected in the build was the inclusion of CFLAGS and LDFLAGS. This allowed python to find and link against system copies of dependencies required to build modules for which the corresponding variant was off, and build said module. This produces modules with potential system references and allows python builds to diverge from the spec requirements. This PR adds arguments to configure that disable the modules our variants configure to be off. Also updates the python requirements pip expects. Pip unconditonally imports zlib and expat, so python must have both those modules Signed-off-by: John Parent <john.parent@kitware.com>

johnwparent · 2026-10-22T00:30:04Z

Went down this rabbit hole after I observed python fail to build after linking to one zstd and trying to load another version at runtime when the the spec had ~zstd

https://gitlab.spack.io/spack/spack-packages/-/jobs/25332018

(a larger issue of using the wrong docker image for the task I was trying to accomplish with that pipeline exists, but is tangential to this PR)

adamjstewart · 2026-10-22T09:27:13Z

@harshula can you see if this fixes #6903?

adamjstewart · 2026-10-22T09:29:42Z

I'll be honest, this code (especially the comments and type hints) looks suspiciously AI generated...

johnwparent · 2026-10-22T18:15:18Z

I'll be honest, this code (especially the comments and type hints) looks suspiciously AI generated...

I was writing overly verbose prose for at least a decade before the existence of LLMs, the lack of brevity in that one comment is entirely the result of my own inability to be succinct, not LLM generation.

If you do not want to review it further, that is your perogative.

Signed-off-by: John Parent <john.parent@kitware.com>

johnwparent · 2026-10-22T18:30:05Z

Ope, missed the existing issue, thanks for catching that.

Signed-off-by: John Parent <john.parent@kitware.com>

harshula · 2026-10-22T21:57:57Z

@harshula can you see if this fixes #6903?

Hi @johnwparent & @adamjstewart , This test was started more than 7 hours ago, so before the most recent changes to the PR. The reproducer completed successfully:

git clone https://github.com/ACCESS-NRI/ACCESS-OM3
spack env activate -p ./ACCESS-OM3
spack concretize -f
spack install --fail-fast

==> Installing py-pip-26.1.2-nqmdw2cwc3z4gcxe2a6tbcdgr3bp5otp [40/66]
==> Fetching https://mirror.spack.io/_source-cache/archive/38/382ff9f685ee3bc25864f820aa50505825f10f5458ffff07e30a6d96e5715cab.whl
    [100%]    1.81 MB @   37.0 MB/s
==> No patches needed for py-pip
==> py-pip: Executing phase: 'install'
==> Error: ProcessError: Command exited with status 1:
    '/opt/release/linux-x86_64_v4/python-venv-1.0-k5x7zrprr7ekuegoetucfftsdxsnkqpv/bin/python3' '/tmp/root/spack-stage/spack-stage-py-pip-26.1.2-nqmdw2cwc3z4gcxe2a6tbcdgr3bp5otp/pip-26.1.2-py3-none-any.whl/pip' '-vvv' '--no-input' '--no-cache-dir' '--disable-pip-version-check' 'install' '--no-deps' '--ignore-installed' '--no-build-isolation' '--no-warn-script-location' '--no-index' '--prefix=/opt/release/linux-x86_64_v4/py-pip-26.1.2-nqmdw2cwc3z4gcxe2a6tbcdgr3bp5otp' '/tmp/root/spack-stage/spack-stage-py-pip-26.1.2-nqmdw2cwc3z4gcxe2a6tbcdgr3bp5otp/pip-26.1.2-py3-none-any.whl'
See build log for details:
  /tmp/root/spack-stage/spack-stage-py-pip-26.1.2-nqmdw2cwc3z4gcxe2a6tbcdgr3bp5otp/spack-build-out.txt

git remote add johnwparent https://github.com/johnwparent/spack-packages
git fetch -pP --all
git cherry-pick 28533b2
Fix conflict in repos/spack_repo/builtin/packages/py_pip/package.py
spack concretize -f
spack install --fail-fast

==> Installing python-3.12.13-yufcyyxlubv3b2zv6cj6n7mkfile25rr [30/65]
==> Using cached archive: /opt/sourcecache/_source-cache/archive/08/0816c4761c97ecdb3f50a3924de0a93fd78cb63ee8e6c04201ddfaedca500b0b.tgz
==> Ran patch() for python
==> python: Executing phase: 'configure'
==> python: Executing phase: 'build'
==> python: Executing phase: 'install'
==> python: Successfully installed python-3.12.13-yufcyyxlubv3b2zv6cj6n7mkfile25rr
  Stage: 0.39s.  Configure: 34.63s.  Build: 11.33s.  Install: 3.66s.  Post-install: 0.32s.  Total: 50.37s
...
==> Installing access-om3-latest-svc3r7655uqdcediokcw6m7hwq5we37i [65/65]
==> No patches needed for access-om3
==> access-om3: Executing phase: 'install'
==> access-om3: Successfully installed access-om3-latest-svc3r7655uqdcediokcw6m7hwq5we37i
  Stage: 0.00s.  Install: 0.00s.  Post-install: 0.03s.  Total: 0.06s
[+] /opt/release/linux-x86_64_v4/access-om3-latest-svc3r7655uqdcediokcw6m7hwq5we37i
==> Updating view at /opt/ACCESS-OM3/.spack-env/view

adamjstewart · 2026-10-23T19:04:21Z

Would it be fun/worthwhile to open a PR that changes all variants to default to False just to see what breaks? Could apply to all packages, not just Python.

johnwparent · 2026-10-23T19:08:33Z

Would it be fun/worthwhile to open a PR that changes all variants to default to False just to see what breaks? Could apply to all packages, not just Python.

I don't know why, but my Spack instance on my mac is doing exactly that, which is how I found the other modules that the CI job that crashed on ~zstd did not.

So yes, I think variant default to off is a great idea. I'm currently working on what we test in CI, I'll fold that into that work. I don't know if we want to hammer Gitlab CI at this specific moment, my current work uses (abuses) GHA free runners to test more spack packages than we normally do in GL.

Signed-off-by: John Parent <john.parent@kitware.com>

adamjstewart · 2026-10-23T19:23:37Z

I was actually just thinking to do this once in a draft PR and then close it later, wasn't thinking about merging it across all of CI permanently, but that might not be such a bad idea. I do think that we should build fully-featured things by default, and I do want to populate the build cache with useful packages though.

adamjstewart

Looks pretty solid to me now! Wish Python made it simpler, but Python itself is a big thing so I guess we can't expect a simple package recipe either.

johnwparent · 2026-10-23T19:41:07Z

I do think that we should build fully-featured things by default, and I do want to populate the build cache with useful packages though.

I fully agree, I think we need a divergence between "tested package configurations" and "things that need to be shipped in the binary mirror". Our current strategy does an incredible amount of testing and produces so many very usable binaries, but because we're not testing things we don't want to ship, less popular configurations rot, as I'm sure you're way too aware.

In an ideal world, we have a GHA CI job that tests whatever packages changes that have been made in a given packages PR so we at least know that PR builds. I know Ryan had that PR'd (or maybe in a branch) to run that on Gitlab CI, but it never took off for cost/build cache constraints.

Then I want to build out a matrix of continuously running jobs that tries to cover... well most of Spack exhaustively. That latter bit is pretty prohibitive for... a lot of reasons (If I had infinite time and money, maybe not) but I think we can do a decent "best attempt" pass and get a lot of benefit.

wdconinc · 2026-10-25T16:42:10Z

This has a CI failure in py-ml-dtypes, https://gitlab.spack.io/spack/spack-packages/-/jobs/25401492 (looks like a missing eigen dependency; not obviously related to this PR).

spackbot-triage Bot requested review from adamjstewart, pradyunsg and scheibelp October 22, 2026 00:23

adamjstewart reviewed Oct 22, 2026

View reviewed changes

Comment thread repos/spack_repo/builtin/build_systems/python.py Outdated

remove redundant constraints

e5ac7c1

Signed-off-by: John Parent <john.parent@kitware.com>

spackbot-triage Bot removed the conflicts Modifications with a `conflicts()` directive label Oct 22, 2026

spackbot-triage Bot requested a review from adamjstewart October 22, 2026 18:27

johnwparent commented Oct 22, 2026

View reviewed changes

Comment thread repos/spack_repo/builtin/packages/python/package.py Outdated

johnwparent added 2 commits October 22, 2026 14:31

readline's curses requirement expressed through readline's dependencies

e2d1709

Signed-off-by: John Parent <john.parent@kitware.com>

drop unused import

1b51cfd

Signed-off-by: John Parent <john.parent@kitware.com>

spackbot-triage Bot removed the build-systems Related to package build systems label Oct 22, 2026

adamjstewart reviewed Oct 23, 2026

View reviewed changes

Comment thread repos/spack_repo/builtin/packages/py_pip/package.py

Comment thread repos/spack_repo/builtin/packages/python/package.py Outdated

Further update python dependencies version constraints

0d07d9d

Signed-off-by: John Parent <john.parent@kitware.com>

spackbot-triage Bot requested a review from adamjstewart October 23, 2026 19:18

adamjstewart approved these changes Oct 23, 2026

View reviewed changes

johnwparent enabled auto-merge (squash) October 23, 2026 19:41

Conversation

johnwparent commented Oct 22, 2026 • edited by adamjstewart Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

johnwparent commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adamjstewart commented Oct 22, 2026

Uh oh!

Uh oh!

adamjstewart commented Oct 22, 2026

Uh oh!

johnwparent commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

johnwparent commented Oct 22, 2026

Uh oh!

harshula commented Oct 22, 2026

Uh oh!

Uh oh!

Uh oh!

adamjstewart commented Oct 23, 2026

Uh oh!

johnwparent commented Oct 23, 2026

Uh oh!

adamjstewart commented Oct 23, 2026

Uh oh!

adamjstewart left a comment

Choose a reason for hiding this comment

Uh oh!

johnwparent commented Oct 23, 2026

Uh oh!

wdconinc commented Oct 25, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

johnwparent commented Oct 22, 2026 •

edited by adamjstewart

Loading

johnwparent commented Oct 22, 2026 •

edited

Loading

johnwparent commented Oct 22, 2026 •

edited

Loading