Skip to content

Conditionally build Python-dependent Lyrical libraries across Pythons 3.12-3.14 - #193

Open
EzraBrooks wants to merge 2 commits into
RoboStack:mainfrom
EzraBrooks:lyrical-python-abi
Open

EzraBrooks wants to merge 2 commits into
RoboStack:mainfrom
EzraBrooks:lyrical-python-abi

Conversation

@EzraBrooks

@EzraBrooks EzraBrooks commented Nov 4, 2026 •

Copy link
Copy Markdown
Contributor

@EzraBrooks EzraBrooks changed the title Lyrical Python 3.12-3.14 support Conditionally build Python-dependent Lyrical libraries across Pythons 3.12-3.14 Nov 4, 2026
@EzraBrooks

This comment has been minimized.

@Tobias-Fischer

Copy link
Copy Markdown
Collaborator

Ok I think we have all the building blocks for this now @EzraBrooks :)

@Tobias-Fischer
Tobias-Fischer marked this pull request as ready for review November 9, 2026 00:33
Tobias-Fischer added a commit that referenced this pull request Nov 10, 2026
With several Python versions pinned (lyrical, #193), a recipe with Python
content makes one build per version, and the estimate counted recipes,
not builds: #193's linux-64 run had 3474 builds where the estimate said
2487 packages.

build_timings.variant_builds counts each recipe's builds from the
multi-valued variant keys its build/host requirements name without a
version (zipped keys as one axis, conditions evaluated for a native
build), from the work dir's conda_build_config.yaml. ci_estimate counts
builds, and a cached build per variant (the cache holds each variant's
package). build-ci records a recipe's time per build (each variant's
span, averaged), and vinca_timings multiplies it by the recipe's builds
for packing the jobs.

check_dependency_compat: variant_values and zip_groups; variant_pins
now uses variant_values (same output, checked on all distros/platforms).

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
@EzraBrooks

Copy link
Copy Markdown
Contributor Author

is it time to re-run CI here?

@EzraBrooks

Copy link
Copy Markdown
Contributor Author

I'm investigating the failure

@EzraBrooks

Copy link
Copy Markdown
Contributor Author

Claude suspects a race condition in build parallelism in rattler-build. Seems suspicious, but I'll chase that down. If that's the case then we might be able to just get away with a cached re-run here.

@EzraBrooks

Copy link
Copy Markdown
Contributor Author

Ah it is indeed prefix-dev/rattler-build#2931 which @Tobias-Fischer already found

…d#2931

A build or test waited for any variant of a dependency, not the one it can
install: e.g. a Python 3.13 test started once the 3.12 package it needs was
built, and failed to solve. The pre-releases (built from main, for linux-64,
osx-arm64 and win-64; built for glibc 2.28) from prefix.dev's
rattler-build-pre-release channel, and the same commit built from git on
osx-64 and linux-aarch64. patchelf, which only conda-forge's package depends
on, is added on Linux. Locked with pixi 0.81.0, the workflows' version: the
source packages' identity differs between pixi versions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants