Repository navigation
chore: drop comments from Project.toml files - #147
Conversation
Org policy: Project.toml carries no comments. Pkg silently drops them the next time anything rewrites the file, so a note there reads fine until the first Pkg.add and then vanishes without trace. Some had already gone stale and now say the opposite of what is true. Co-authored-by: Sam Abbott <contact@samabbott.co.uk>
Try this Pull Request!Option 1: Julia Package ManagerOpen Julia and type: import Pkg
Pkg.activate(temp=true)
Pkg.add(url="https://github.com/EpiAware/DistributionsInference.jl", rev="chore/no-comments-in-project-toml")
using DistributionsInferenceOption 2: Local CheckoutIf you have the repo locally: git checkout chore/no-comments-in-project-toml
julia --project=. -e "using Pkg; Pkg.instantiate()" |
Codecov Report✅ All modified and coverable lines are covered by tests.
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
|
📖 Documentation preview is ready! View the docs for this PR at: https://EpiAware.github.io/DistributionsInference.jl/previews/PR147/ This preview will be updated automatically when you push new commits. |
![seabbs-review-bot[bot]](https://avatars.githubusercontent.com/in/4624046?s=60&v=4){kind=small}
There was a problem hiding this comment.
This PR only strips comments from six Project.toml files; no version bounds or resolution behaviour change. Some deletions correctly remove history/issue-number narration the org standards ban, but others delete "why" comments that documented non-obvious compat constraints and cross-file couplings, with no equivalent explanation left anywhere in the repo.
Automated first pass by seabbs-review-bot (Claude sonnet), triggered by: first pass. Not a human review. Comment @seabbs-review-bot to ask for another pass: @seabbs any time, the author's agent once it has pushed changes. Add the no-review label to opt this PR out. Ping @seabbs with any questions.
| # `Distributions.ProductNamedTupleDistribution`, added in that release. An | ||
| # unbounded "0.25" lets `downgrade-compat` resolve an older Distributions | ||
| # that DynamicPPL/Bijectors then fail to precompile against. | ||
| Distributions = "0.25.117" |
There was a problem hiding this comment.
issue This deleted the only explanation for why Distributions is floored at 0.25.117 (DynamicPPL's debug_utils.jl references Distributions.ProductNamedTupleDistribution, added in that release). That's exactly the kind of comment julia-standards.md rule 7 asks to keep: a constraint invisible in the code. It isn't documented anywhere else in the repo (checked NEWS.md and docs/). A future contributor loosening this bound during a routine compat bump now has nothing to warn them why it's pinned there. Restore a short version, e.g. # Floored at 0.25.117: DynamicPPL's debug_utils.jl needs Distributions.ProductNamedTupleDistribution, added in that release.
| # matrix (lts/1/pre). Unpinned, the version floats per job, so `test (1)` and | ||
| # `pre-commit` reformat files that `test (lts)` left alone. Keep in step with | ||
| # the `.pre-commit-config.yaml` JuliaFormatter `rev` and the CI format-check. | ||
| JuliaFormatter = "=2.10.1" |
There was a problem hiding this comment.
issue The deleted comment explained that this pin must stay in step with .pre-commit-config.yaml's JuliaFormatter rev. That coupling still exists and is still referenced from the other side: .pre-commit-config.yaml lines 46-47 say "Keep rev in step with the pinned JuliaFormatter in the formatter test environment", pointing back at this file. With this comment gone the cross-reference is now one-sided, so an editor bumping this pin has no signal to also update the pre-commit hook. Keep a short pointer, e.g. # Pinned exactly; keep in step with .pre-commit-config.yaml's JuliaFormatter rev.
| # `DimensionalData` at 0.28.3 while the `FlexiChains` these docs load needs | ||
| # >=0.29.24 (kit#283). Restore those deps, and `docs` as a workspace member, | ||
| # once that ceiling lifts. | ||
| [deps] |
There was a problem hiding this comment.
suggestion This deleted both the "PACKAGE-OWNED — scaffold writes this once and never overwrites it" note and the DimensionalData/AlgebraOfGraphics ceiling explanation (kit#283) for why the plotting stack is absent from this env. Unlike the formatter and root Project.toml comments, this one also carried a live external tracking reference, so removing it is more defensible under rule 8, but the scaffold-ownership semantics (hand edits here survive template sync, unlike test/formatter/Project.toml which is machine-managed) aren't recorded anywhere else. Consider keeping at least the one-line ownership note.
2 participants
Org policy:
Project.tomlcarries no comments.Pkg silently drops them the next time anything rewrites the file —
Pkg.add,Pkg.compat!, a dependency bump — so a note there reads fine until the first routine edit and then vanishes without trace. The kit makes this argument to adopters itself, in its_project_toml_comment_gapdiagnostic.Comment removal only. No dependency, compat or
[sources]entry is touched, and every file still parses as TOML (checked withtomllib).This was opened by a bot. Please ping @seabbs for any questions.