deps: track pyiron_workflow_atomistics 0.0.7 pin set#41
Merged
Conversation
Bump the runtime pin block to match the versions that pyiron-workflow-atomistics==0.0.6 (already pinned here) actually requires, so installs stop conflicting with the upstream resolver. Verbatim from pwa 0.0.6's METADATA: - pandas 2.3.1 -> 3.0.2 - ase 3.26.0 -> 3.28.0 - scipy 1.16.1 -> 1.17.1 - pymatgen 2025.6.14 -> 2026.5.4 - scikit-learn 1.7.2 -> 1.8.0 Numpy / matplotlib / pyiron-workflow / pyiron-snippets / tqdm / lz-GB-code already match upstream; pyiron_lammps stays at 0.4.6 (its own bump to 0.5.4 is being tracked separately in #36 and needs a parser-API review before merging). Updated in lockstep: - pyproject.toml - .ci_support/environment.yml - .ci_support/lower-bound.yml - .binder/environment.yml Closes the coordinated-bump scope flagged in the open-PR triage: supersedes #19 (pymatgen), #30 (ase), #33 (pandas), #37 (numpy); those should be closed once this lands. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0.0.7 (released 2026-05-14) replaces pwa's exact == pins with bounded ranges (e.g. numpy <1.27.0,>=1.22.0, ase <3.29.0,>=3.21.0, pymatgen <2026.6.0,>=2024.8.8). Every version this branch already chose for the runtime block sits inside those ranges, so the only file edit needed is the pwa pin itself across: - pyproject.toml - .ci_support/environment.yml - .ci_support/lower-bound.yml - .binder/environment.yml Side benefit: with pwa 0.0.7's looser ranges, the future Dependabot PRs against pandas / ase / pymatgen / scikit-learn become resolvable without a second coordinated bump on the pwa side. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Was missed in the previous commit; the CI's [dependabot skip] runner had auto-mirrored the runtime-block bumps into docs/environment.yml but did not touch the pwa pin itself, leaving docs out of sync with the rest of the env files. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 15, 2026
ligerzero-ai
added a commit
that referenced
this pull request
May 15, 2026
PR #41 bumped ase to 3.28.0 and pandas to 3.0.2 to match what pwa 0.0.7 *allows*, but pyiron_lammps (any released version, including 0.5.4) caps ase at <=3.27.0 and pandas at <=3.0.0 -- both on PyPI and on conda-forge. Likewise pysqa 0.3.0 caps pandas at <=2.3.1. Result: every CI job that creates a conda env (test-alternate-env, build-docs, build-notebooks, coverage, benchmark-tests, pip-check, unit-tests/macos, pypi-release) failed with `libmamba Could not solve for environment specs`. Main has been red since 5701c50. Fix-forward: pull ase / pandas / scipy back to the largest values that satisfy ALL of {pwa 0.0.7, pyiron_lammps 0.5.4, pysqa 0.4.0}, and bump pyiron_lammps + pysqa themselves so the rest of the upgrade we already shipped doesn't have to revert: ase 3.28.0 -> 3.27.0 (cap from pyiron_lammps 0.5.4) pandas 3.0.2 -> 3.0.0 (cap from pyiron_lammps 0.5.4) scipy 1.17.1 -> 1.17.0 (cap from pyiron_lammps 0.5.4) pyiron_lammps 0.4.6 -> 0.5.4 (latest; needed to lift the conda pin `ase <=3.26.0` from 0.4.6) pysqa 0.3.0 -> 0.4.0 (latest; lifts pandas cap) Verified locally with `pixi add` against conda-forge: full env solves clean. API check for pyiron_lammps 0.5.4 vs the two functions pwl uses (`write_lammps_structure`, `parse_lammps_output_files`): - write_lammps_structure: only added a trailing optional kwarg `atom_type='atomic'`. Pwl call site at lammps.py:24-30 uses only the original kwargs. Backward-compatible. - parse_lammps_output_files: signature identical, output dict structure (generic.cells/positions/indices/energy_tot/forces/ pressures/steps) unchanged. Updated in lockstep across: - pyproject.toml (runtime + cluster extra) - .ci_support/environment.yml - .ci_support/lower-bound.yml - .binder/environment.yml - docs/environment.yml Supersedes #35 (pysqa) and #36 (pyiron_lammps) -- close after merge. Co-authored-by: Han Mai <ligerzerof@gmail.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bumps the runtime pin block to be compatible with
pyiron-workflow-atomistics==0.0.7(latest, released 2026-05-14).pwa 0.0.7switched from exact==Xpins to bounded ranges (e.g.numpy <1.27.0,>=1.22.0,ase <3.29.0,>=3.21.0,pymatgen <2026.6.0,>=2024.8.8), which is much easier on the resolver. The version values picked here all sit comfortably inside those ranges, while still matching what pwa 0.0.6 used to pin exactly — so installs are clean against either.pyiron-lammpsstays at0.4.6— its bump to 0.5.4 is tracked in #36 and needs a parser-API review before merging.Updated in lockstep:
pyproject.toml.ci_support/environment.yml.ci_support/lower-bound.yml.binder/environment.ymldocs/environment.ymlSupersedes (close on merge)
<1.27.0)Test plan
pip install -e .resolves cleanly alongsidepyiron-workflow-atomistics==0.0.7(no resolver conflict warnings).notebooks/EnginePrototype_lammps.ipynbstill runs end-to-end against a LAMMPS build with theMANYBODYpackage.🤖 Generated with Claude Code