Conversation
WalkthroughThe project’s build and versioning system was migrated from setuptools and versioneer to hatchling and hatch-vcs. This involved updating configuration files, modifying CI/CD workflows, and replacing dynamic version computation with static version variables. All references to versioneer were removed, and hatchling-based build steps and dependencies were introduced throughout. Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant GitHub Actions
participant Hatchling
participant PyPI
Developer->>GitHub Actions: Push code / PR / Tag
GitHub Actions->>Hatchling: Run `hatchling build -t sdist -t wheel`
Hatchling->>GitHub Actions: Build distributions using VCS version
GitHub Actions->>PyPI: Publish built distributions
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15 minutes Poem
Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. 📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (10)
📒 Files selected for processing (8)
✅ Files skipped from review due to trivial changes (7)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #239 +/- ##
=======================================
Coverage 95.17% 95.17%
=======================================
Files 4 4
Lines 497 497
=======================================
Hits 473 473
Misses 24 24 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🔭 Outside diff range comments (1)
.github/workflows/deploy.yml (1)
21-29: Fetch full history for hatch-vcs to see tags.hatch-vcs needs tags to compute versions. Configure checkout to fetch tags/history.
Add this to the checkout step:
- uses: actions/checkout@v4 with: fetch-depth: 0 fetch-tags: true
🧹 Nitpick comments (5)
.ci_support/environment.yml (1)
4-5: Build-time tools in test environment.Adding
hatchlingandhatch-vcshere is fine if CI builds artifacts. If they’re not needed for runtime/tests, consider moving them to a dedicated build env (workflow step) to keep CI lean.pyiron_lammps/__init__.py (1)
1-1: Absolute import is fine; consider exposing version.Importing
pyiron_lammps._versionis OK. Optionally add"__version__"to__all__for convenience when users dofrom pyiron_lammps import *.binder/environment.yml (2)
10-11: EOF newline missing; YAML lint failure.YAMLlint reports missing trailing newline at EOF. Add a newline to satisfy linters and tooling.
Minimal fix: ensure the file ends with a newline character.
10-11: Do we need build backend in Binder?Pinning
hatchlingandhatch-vcsin Binder increases image size. If Binder sessions don’t build distributions, consider removing them.pyproject.toml (1)
51-55: Consolidate hatch build configuration to avoid duplicationYou define includes in three places:
[tool.hatch.build].include,[tool.hatch.build.targets.sdist].include, and[tool.hatch.build.targets.wheel].packages. This duplication is easy to get out of sync.Suggestion: Drop the top-level
[tool.hatch.build]include and keep only the target-specific sections.-[tool.hatch.build] -include = [ - "pyiron_lammps" -]This keeps sdist/wheel configuration as the single source of truth.
Also applies to: 59-63, 64-67
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
.ci_support/environment.yml(1 hunks).github/workflows/deploy.yml(1 hunks).github/workflows/pipeline.yml(1 hunks)binder/environment.yml(1 hunks)pyiron_lammps/__init__.py(2 hunks)pyiron_lammps/_version.py(1 hunks)pyproject.toml(2 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
binder/environment.yml
[error] 11-11: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (2)
pyiron_lammps/__init__.py (1)
16-16: Ensure dynamic version injection instead of relying on a committed stubThe line
__version__ = pyiron_lammps._version.__version__will always read the static
_version.pychecked into source control unless your build process overwrites it. Please verify that:
- The repository does not ship a stale
_version.pystub.- Your project configuration (e.g.
pyproject.tomlorhatch.toml) enables thehatch-vcs(or equivalent) plugin to auto-generate/write the correct version at build time.- Installing or building the package via
pip install .orhatch buildinjects the intended version into_version.py.If not already in place, consider removing
_version.pyfrom VCS and configuringhatch-vcsto write the version file during setup. Would you like a patch for that change?pyproject.toml (1)
56-57: VCS versioning setup verified ✅
pyiron_lammps/_version.pydefines
__version__ = version = "0.0.1"pyiron_lammps/__init__.pyimports and surfaces it via
__version__ = pyiron_lammps._version.__version__No further changes needed here.
| git update-index --assume-unchanged pyproject.toml pyiron_lammps/_version.py | ||
| hatchling build -t sdist -t wheel |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fragile Git index hack; prefer proper VCS-versioning setup.
git update-index --assume-unchanged is a local hack that doesn’t affect sdist contents and can hide real changes. Also, hatchling build is likely not the intended CLI; typically use hatch build or python -m build.
Proposed changes in this step:
- git update-index --assume-unchanged pyproject.toml pyiron_lammps/_version.py
- hatchling build -t sdist -t wheel
+ # Ensure a clean state; no index hacks needed
+ # Build using the front-end or hatch CLI
+ python -m pip install --upgrade build
+ python -m build --sdist --wheelIf you prefer Hatch:
- Add
hatchto the environment and runhatch build.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| git update-index --assume-unchanged pyproject.toml pyiron_lammps/_version.py | |
| hatchling build -t sdist -t wheel | |
| # Ensure a clean state; no index hacks needed | |
| # Build using the front-end or hatch CLI | |
| python -m pip install --upgrade build | |
| python -m build --sdist --wheel |
🤖 Prompt for AI Agents
In .github/workflows/deploy.yml at lines 35-36, remove the fragile git index
hack using 'git update-index --assume-unchanged' as it does not affect sdist
contents and can hide changes. Replace the 'hatchling build -t sdist -t wheel'
command with 'hatch build' after ensuring 'hatch' is installed in the
environment. This aligns with proper VCS-versioning and standard build
practices.
| shell: bash -l {0} | ||
| run: | | ||
| pip install versioneer[toml]==0.29 tomlkit | ||
| pip install tomlkit |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Ensure hatch build backend is available when using --no-build-isolation
With the migration to hatchling/hatch-vcs, pip install . --no-build-isolation requires both hatchling and hatch-vcs to be preinstalled in the environment. This step only installs tomlkit. Please verify they’re present in .ci_support/environment*.yml; otherwise, the build can fail at sdist/wheel build time.
Run this to confirm the environment includes the hatch backend tools:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Checking .ci_support/environment.yml and environment-old.yml for hatch tooling..."
for f in .ci_support/environment.yml .ci_support/environment-old.yml; do
if [ -f "$f" ]; then
echo "File: $f"
rg -n 'hatchling|hatch-vcs' "$f" || echo "NOT FOUND in $f"
else
echo "Missing: $f"
fi
doneLength of output: 829
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Searching for environment YAML references in .github/workflows/pipeline.yml..."
rg -n 'environment(-old)?\.yml' .github/workflows/pipeline.yml || echo "No environment file references found."Length of output: 738
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Context around the pip install tomlkit step in pipeline.yml:"
rg -n -C5 'pip install tomlkit' .github/workflows/pipeline.yml
echo
echo "Context around the environment-old.yml reference in pipeline.yml:"
rg -n -C5 'environment-old\.yml' .github/workflows/pipeline.ymlLength of output: 1172
Add hatchling & hatch-vcs to the old CI environment
The Python 3.9 job in .github/workflows/pipeline.yml (lines ~190–200) uses .ci_support/environment-old.yml and then runs:
pip install tomlkit
…
pip install . --no-deps --no-build-isolationSince you’ve migrated to hatchling/hatch-vcs, both backends must be preinstalled for a no-build-isolation install. While .ci_support/environment.yml already lists hatchling and hatch-vcs, the old environment file does not. Please add:
- hatchling
- hatch-vcsto .ci_support/environment-old.yml to prevent sdist/wheel build failures.
🤖 Prompt for AI Agents
In .github/workflows/pipeline.yml around line 135, the old CI environment used
by the Python 3.9 job lacks hatchling and hatch-vcs in its dependencies, causing
build failures during no-build-isolation installs. To fix this, add "hatchling"
and "hatch-vcs" to the dependencies list in the .ci_support/environment-old.yml
file so these backends are preinstalled before running pip install commands.
| # file generated by setuptools-scm | ||
| # don't change, don't track in version control |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Header contradicts PR goal (setuptools-scm vs hatch-vcs).
This file claims to be generated by setuptools-scm, but the PR migrates to hatchling + hatch-vcs. Align the source of truth to avoid confusion.
Suggested actions:
- If using hatch-vcs, remove this file from VCS and let hatch-vcs write the version at build time.
- Or at least update the header to reflect hatch-vcs if you decide to keep a stub.
🤖 Prompt for AI Agents
In pyiron_lammps/_version.py at lines 1 to 2, the header incorrectly states the
file is generated by setuptools-scm, conflicting with the PR's migration to
hatchling and hatch-vcs. To fix this, either remove this file from version
control entirely so hatch-vcs can generate the version at build time, or update
the header comment to accurately reflect that hatch-vcs is now the source of
version information if you choose to keep the file as a stub.
There was a problem hiding this comment.
🛠️ Refactor suggestion
Hard-coded version defeats VCS-based versioning.
__version__ = "0.0.1" is static. With hatch-vcs, version should come from tags; a committed stub risks shipping the wrong version.
Recommended:
- Remove this file and configure hatch-vcs to write the version during build (e.g., using the hatch-vcs write-to option).
- Alternatively, keep a minimal placeholder guarded for type-checkers only and ensure runtime builds always overwrite it.
🤖 Prompt for AI Agents
In pyiron_lammps/_version.py at lines 19-20, the version is hard-coded which
conflicts with hatch-vcs dynamic versioning from tags. To fix this, remove this
file entirely and configure hatch-vcs to write the version during the build
process using its write-to option. Alternatively, keep only a minimal
placeholder version string guarded by type-checking conditions and ensure the
actual version is overwritten at runtime by hatch-vcs.
| requires = [ | ||
| "ase", | ||
| "numpy", | ||
| "h5py", | ||
| "pandas", | ||
| "scipy", | ||
| "hatchling==1.27.0", | ||
| "hatch-vcs==0.5.0", | ||
| ] |
There was a problem hiding this comment.
Move runtime dependencies out of [build-system].requires (PEP 517 compliance)
[build-system].requires must list only the build backend and its immediate requirements. Including runtime deps (ase, numpy, h5py, pandas, scipy) here forces heavy/unnecessary installs during build and leaks optional deps (e.g., h5py) into every build.
Apply:
[build-system]
requires = [
- "ase",
- "numpy",
- "h5py",
- "pandas",
- "scipy",
"hatchling==1.27.0",
"hatch-vcs==0.5.0",
]
build-backend = "hatchling.build"Note: Keep runtime deps under [project.dependencies]/extras only.
🤖 Prompt for AI Agents
In pyproject.toml lines 2 to 10, the runtime dependencies (ase, numpy, h5py,
pandas, scipy) are incorrectly listed under [build-system].requires. To fix
this, remove these runtime dependencies from [build-system].requires and instead
list only the build backend and its immediate requirements there. Then, add the
runtime dependencies under the [project.dependencies] section or appropriate
extras section to comply with PEP 517 and avoid unnecessary installs during
build.
1 participant
Summary by CodeRabbit
Chores
Refactor