Skip to content

ENH: pixi-packages: use skip-pyc-compilation for tsan-freethreading - #31558

Draft
lucascolley wants to merge 1 commit into
numpy:mainfrom
lucascolley:tsan-ft-skip-pyc
Draft

ENH: pixi-packages: use skip-pyc-compilation for tsan-freethreading#31558
lucascolley wants to merge 1 commit into
numpy:mainfrom
lucascolley:tsan-ft-skip-pyc

Conversation

@lucascolley

Copy link
Copy Markdown
Contributor

No description provided.

@lucascolley
lucascolley force-pushed the tsan-ft-skip-pyc branch 2 times, most recently from cd9a52a to 312e37a Compare June 4, 2026 09:45
@lucascolley
lucascolley marked this pull request as ready for review June 4, 2026 09:45
@lucascolley

Copy link
Copy Markdown
Contributor Author

cc @ngoldbaum @crusaderky

@ngoldbaum

Copy link
Copy Markdown
Member

Hmm, ~30 minutes is still the slowest CI job by a good margin 🫤

@lucascolley

Copy link
Copy Markdown
Contributor Author

Hmm, ~30 minutes is still the slowest CI job by a good margin 🫤

looks like ubuntu-arm and macOS are faster, perhaps we can merge if we skip ubuntu?

@lucascolley

Copy link
Copy Markdown
Contributor Author

let me see if this is any faster with adding skip_pyc_compilation for the CPython package too before doing that

@lucascolley

Copy link
Copy Markdown
Contributor Author

@ngoldbaum I've got it down to 24 mins, how close is that to acceptable?

@ngoldbaum

Copy link
Copy Markdown
Member

Looking at a recent CI run, the three slowest builds were:

  • macOS x86-64 conda (3.12) - 35:36
  • Build wheel cp312-manylinux_riscv64 - 26:24
  • riscv64 - 22:40

So it would be slow, but not the slowest or even the second-slowest. So on that account it's probably OK to go in.

Can you explain again what the marginal benefit of having the CI run going is? I've never actually noticed these pixi CI jobs failing because of issues in the pixi setups so I'm not sure how often they'll pick up bugs that other CI jobs would miss.

@rgommers you usually have good intuition about this - what do you say about enabling this CI job?

@lucascolley

Copy link
Copy Markdown
Contributor Author

Can you explain again what the marginal benefit of having the CI run going is? I've never actually noticed these pixi CI jobs failing because of issues in the pixi setups so I'm not sure how often they'll pick up bugs that other CI jobs would miss.

admittedly, the use of enabling it right now when the number of downstream users of these packages is O(0) (unless @crusaderky has been making industrious use of them?) is negligible. However, in a future where SciPy et al. are using these packages, I think it is significantly preferable that issues hit NumPy CI before they hit downstream.

As for what they will pick up that other jobs won't, I suppose it is problems specific to NumPy's interaction with the conda-forge compiler toolchains and these special build variants. Maybe the coverage elsewhere is good enough ™️ but I still feel like this is nice to have before we introduce these packages into SciPy's workspace.

@lucascolley

Copy link
Copy Markdown
Contributor Author

@lucascolley
lucascolley marked this pull request as draft June 26, 2026 17:31
@rgommers

Copy link
Copy Markdown
Member

In general, 24 minutes seems fine to enable, and if it becomes a problem we reserve the right to change our minds. It's in the right ball park I'd say for a TSan job.

@lucascolley

Copy link
Copy Markdown
Contributor Author

not blocking here, but python/cpython#152385 is also pretty exciting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants