Hi there,
I'm writing to suggest an enhancement for the vimeo/psalm project to improve its integration and ensure long-term reliability, particularly for package managers like apt, rpm, yum, nix, etc etc.
The primary goal here is to enable reproducibility of the exact build of the PHAR released, down to the last bit. This is crucial, especially when distributing it as a binary for reasons of reliability and security.
To achieve this, I propose adding a composer.lock file to the vimeo/psalm repository. This file will ensure that psalm is reproducible on any system, regardless of environmental differences, by locking down specific versions of dependencies. Its absence currently hinders the ability to precisely replicate the builds you provide in your GitHub releases, introducing potential variability.
For example, in Nix, we have to provide our own composer.lock for each update, as seen here: NixOS/nixpkgs#271920
For reference, here are some projects that have recognized the value of versioning the composer.lock file:
If there are concerns about including the composer.lock file in the main repository, could it be an option to add it to the release artifacts on GitHub instead? This compromise would still greatly benefit reproducibility and consistency in dependency management.
Thank you for considering this enhancement. I look forward to your response.
Hi there,
I'm writing to suggest an enhancement for the
vimeo/psalmproject to improve its integration and ensure long-term reliability, particularly for package managers like apt, rpm, yum, nix, etc etc.The primary goal here is to enable reproducibility of the exact build of the PHAR released, down to the last bit. This is crucial, especially when distributing it as a binary for reasons of reliability and security.
To achieve this, I propose adding a
composer.lockfile to thevimeo/psalmrepository. This file will ensure thatpsalmis reproducible on any system, regardless of environmental differences, by locking down specific versions of dependencies. Its absence currently hinders the ability to precisely replicate the builds you provide in your GitHub releases, introducing potential variability.For example, in Nix, we have to provide our own
composer.lockfor each update, as seen here: NixOS/nixpkgs#271920For reference, here are some projects that have recognized the value of versioning the
composer.lockfile:composer.lockfile in the repository bobthecow/psysh#767composer.lockfile in the repository phpro/grumphp#1095If there are concerns about including the
composer.lockfile in the main repository, could it be an option to add it to the release artifacts on GitHub instead? This compromise would still greatly benefit reproducibility and consistency in dependency management.Thank you for considering this enhancement. I look forward to your response.