ProteoMaker

Imported from computproteomics/ProteoMaker (AGENTS.md). Install upstream with npx skills add computproteomics/ProteoMaker. Copyright stays with the author.

Repository Guidelines

Project Structure & Module Organization

• Source code: R/ with step-wise modules (e.g., 00_BatchRunFuncs.R, 01_GenerateGroundTruth.R, …, 06_Benchmarks.R, Parameter.R).
• Use 00_BachRunFuncs.R for high-level function for the orchestration, and keep them mostly unchanged.
• Tests: tests/testthat/ (edition 3) with files named test-*.R; entry in tests/testthat.R.
• Docs: man/ (roxygen2-generated), vignettes/ (knitr/rmarkdown), README.md.
• Package metadata: DESCRIPTION, NAMESPACE (autogenerated), project file ProteoMaker.Rproj.
• Assets/output: inst/ (shipped resources), Results/ and tmp/ (runtime outputs; ignored in builds).

Build, Test, and Development Commands

• Install: R CMD INSTALL . or R -q -e "devtools::install()"
• Check (full): R CMD build . then R CMD check ProteoMaker_*.tar.gz or R -q -e "devtools::check()"
• Tests only: R -q -e "devtools::test()"
• Docs: R -q -e "devtools::document()" (updates NAMESPACE/man/)
• Vignettes: R -q -e "devtools::build_vignettes()" GitHub Actions runs R-CMD-check on PRs (see .github/workflows/R-CMD-check.yaml).

Coding Style & Naming Conventions

• R style: 2-space indent, soft wrap at ~100 chars, snake_case for functions and objects (e.g., set_proteomaker, run_sims).
• Place new functions in the most relevant numbered module; keep cohesive responsibilities.
• Make cross-checks to avoid redundancies and to place the new functions correctly.
• Keep code short and concise avoiding layers of sanitation and checks.
• Document all exported functions with roxygen2 (@title, @param, @return, @examples, @export).
• Avoid side effects on load; write outputs under Results/ or user-specified paths.

Testing Guidelines

• Use testthat 3e: test_that("…", { … }); name files tests/testthat/test-<topic>.R.
• Prefer small, deterministic tests; mock filesystem with tempdir() where possible.
• Run locally with devtools::test(); CI runs snapshot tests, commit updated snapshots if intentional.

Commit & Pull Request Guidelines

• Commits: short imperative subject (<= 72 chars), body for rationale and context.
• Include examples: "fix: handle NA in def_param" or "feat: add matrix_benchmarks plot options".
• PRs: describe changes, link issues, note breaking changes, include before/after screenshots for plots.
• Ensure devtools::check() passes locally and docs/tests are updated.

Security & Configuration Tips

• Some dependencies install from GitHub (Remotes); ensure a GitHub token in CI when needed.
• Long-running simulations can be resource-intensive; prefer small parameter sets in tests and examples.

General Behavior

• Introduce each suggested change with 1-2 short sentences of the rationale.
• Clearly refer to the part of the code (file and function name) when discussing changes or additions.
• Go step-wise when implementing larger changes, and test each step thoroughly.