Reproducibility in [Infosec] Software Research requires DevOpSec, which requires: explicit data and code dependency specifications, and/or trusting hopefully-immutable software package archives, and/or securely storing and transmitting crytographically-signed archival (container) images; and then Upgrade all of the versions and run the integration tests with a git post-receive hook or a webhook to an external service dependency not encapsulated within the {Dockerfile, environment.yml/requirements.txt/postBuild; REES} dependency constraint model.
Poetry has an "Expanded dependency specification syntax" but FWIU there's not a way to specify unsigned or signed cryptographic hashes, which e.g. Pipfile.lock supports: hashes for every variant of those versions of packages on {PyPI, and third-party package repos with TUF keys, too}.
> pipenv lock is used to create a Pipfile.lock, which declares all dependencies (and sub-dependencies) of your project, their latest available versions, and the current hashes for the downloaded files. This ensures repeatable, and most importantly deterministic, builds
> The replication crisis (also called the replicability crisis and the reproducibility crisis) is an ongoing methodological crisis in which it has been found that the results of many scientific studies are difficult or impossible to reproduce. Because the reproducibility of empirical results is an essential part of the scientific method,[2] such failures undermine the credibility of theories building on them and potentially call into question substantial parts of scientific knowledge.
Just rebuilding or re-pulling a container image does not upgrade the versions of software installed within the container. See also: SBOM, CycloneDx, #LinkedReproducibility, #JupyterREES.
If the versions installed in the book are outdated, you too can bump the version strings in the dependency specs in the git repo and send a PR Pull Request (which also updates the Screenshots and Menu > Sequences and Keyboard Shortcuts in the book&docs); and then manually test that everything works with the updated "deps" dependencies.
If it's an executablebooks/, a Computational Notebook (possibly in a Literate Computing style), you can "Restart & Run all" from the notebook UI button or a script, and then test that all automated test assertions pass, and then "diff" (visually compare), and then just manually read through the textual descriptions of commands to enter (because people who buy a Book presumably have a reasonable expectation that if they copy the commands from the book to a script by hand to learn them, the commands as written should run; it should work like the day you bought it for a projected term of many free word-of-mouth years.
> Most of these compose files are pretty outdated AND they depend on non-standard builds of containers for each respective application.
>> What else would you expect for setups intentionally trying to preserve past versions of software?
So, I wrote about reproducibility in software; and Software Supply Chain Security. Specifically, how to do containers and keep the software versions up to date.
Are you challenging the topicality of my comment on HN - containing original research - to be facetious?
Also, the install instructions suggest installing the python implementation of docker-compose, which has been deprecated in favour of the compose docker plugin.
