ci: force setuptools<82 to fix compilation error from isitgr#1279
ci: force setuptools<82 to fix compilation error from isitgr#1279carlosggarcia merged 43 commits intomasterfrom
Conversation
Replace deprecated GitHub Actions versions and update build processes. Migrate from styfle/cancel-workflow-action to native concurrency feature for canceling redundant builds. Update checkout actions from v2/v3 to v4, setup-python from v2 to v5, and cache from v3 to v4. Switch PyPI publishing to trusted publishing with id-token and update build process from setup.py to python -m build. Add permissions sections to all workflows and fix macOS environment variable handling by using GitHub ENV syntax instead of shell exports. Remove legacy commented code and update cache key generation. Add comprehensive CONTRIBUTING.md with development environment setup guide for both conda and manual setup, testing instructions, and debugging guidance. Add .gitignore files to exclude generated _version.py and notebook conversions.
Add two new steps to the CI workflow to cache pip packages between runs. This reduces build time by reusing downloaded packages across multiple CI jobs and re-runs. The new steps retrieve the pip cache directory and use GitHub Actions cache@v4 to store and restore it, keyed on the environment files and setup.py to ensure cache validity.
The CI workflow now tests against Python versions 3.11, 3.12, 3.13, and 3.14 explicitly. The setup-miniconda step now uses the matrix-specified Python version, and cache keys for both conda and pip environments are now versioned by Python version to prevent cache conflicts.
Enable manual triggering of the CI workflow with customizable parameters. Developers can now test specific Python versions and operating systems without pushing code to the repository. The workflow_dispatch event accepts two inputs: python-version to test individual versions and os to select ubuntu-latest, macos-latest, or all platforms. The matrix strategy was made dynamic to respect these inputs. Added documentation in CONTRIBUTING.md explaining how to manually trigger workflows via GitHub Web Interface and CLI, with practical use cases for testing specific configurations.
The main branch does not exist; this project uses the older standard name, master.
Tighten scipy bound and add dependency update instructions Update environment.yml to require scipy < 1.14 to avoid recent compatibility breakages with velocileptors. Remove the obsolete channel_priority line. Add a new "Updating dependencies" section to CONTRIBUTING.md that documents how to update the conda environment, reinstall pip-listed packages, and recreate the test environment for contributors.
The separate isitgr and classy installation steps in the CI workflow were redundant because both packages are already specified in .github/environment.yml. More importantly, the isitgr step was downgrading setuptools from 82.0.0 to <81 based on an outdated workaround for setuptools issue #5174. The local test environment successfully uses setuptools 82.0.0 with isitgr 1.0.5 and classy 3.3.4.0, proving that the setuptools downgrade is unnecessary. The CI now relies entirely on environment.yml for package versions, matching the working local configuration.
Consolidate developer documentation into readthedocs source files and reference them from CONTRIBUTING.md to reduce duplication. Update project requirements to Python 3.10+ and add missing build dependencies to pyproject.toml. Add a Makefile to streamline local package build testing and cleaning. Update CI configuration to test Python 3.10. Standardize commands for running tests and benchmarks with OMP_NUM_THREADS set to 2. Update environment.yml with version constraints and comments.
Update build, CI and dependencies
|
@gqcristhian added commits that:
|
|
Rebased #1202 by @sankarshana16 into this PR to fix issue 1191 |
nikosarcevic
left a comment
There was a problem hiding this comment.
thank you for this
my suggestion is to not have multiple files in the benchamrk dir but to condense the tsts into 1 file for benchmarking Pk and jsut parametrize. that way everything is ine one place and the code is not duplicated so we are ensuring we are testing all the settings and parametrizations in one place in one script.
|
|
||
|
|
||
| @pytest.fixture(scope='module', params=['fftlog', 'bessel']) | ||
| @pytest.fixture(scope="module", params=["fftlog", "bessel"]) |
There was a problem hiding this comment.
general question -- why are there 3 files for these tests? we should just parametrize and have one file instead of 3 with exactly the same setup
There was a problem hiding this comment.
For legacy reasons. I don't think this PR is the place to address this issue (and I would wait for CCLv3 to be out before changing things)
There was a problem hiding this comment.
ok agreed, good point. we can ask @Lhior to open an issue and do a quick fix or i can do it myself. i tihnk this will be important( but not pressing of course)
| import pytest | ||
|
|
||
| import pyccl as ccl | ||
| from classy import Class |
There was a problem hiding this comment.
same here -- combine the test into one file no need to have testing pk in two differnt files
pyccl/boltzmann.py
Outdated
| cp.omch2 = cosmo['Omega_c'] * h2 | ||
| cp.omk = cosmo['Omega_k'] | ||
| cp.GR = 1 # means GR modified! | ||
| cp.GR = 0 # means GR modified! |
There was a problem hiding this comment.
expand the inline comment and say zero menas that GR is modified
| ] | ||
| dependencies = [ | ||
| "numpy", | ||
| "packaging", |
There was a problem hiding this comment.
do we still need this dependency? IIRC this was the bane of our existence and we do not need it directly (only thru isitgr ).
There was a problem hiding this comment.
i don't think this one is related to the source of the problems. I think this is a handy tool to do different things. @marcpaterno might be able to explain more
There was a problem hiding this comment.
it is used in pyccl/__init__.py, so it has to be kept
Pull Request Test Coverage Report for Build 22499621351Details
💛 - Coveralls |
nikosarcevic
left a comment
There was a problem hiding this comment.
thank you all for fixing this! we are finally green and that is a perfect way to start the weekend.
What the title says.
Source: https://discuss.python.org/t/pkg-resources-removal-how-to-go-from-there/106079
If they end up releasing
pkg_resourcesas a standalone library, we can switch to install that one.