Adding composer.lock under VCS ?

[drupol]

Hi,

I'm writing to suggest an enhancement for this 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 this repository. This file will ensure that the binary produced 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 reference, here are some projects that have recognized the value of versioning the composer.lock file:

• Add composer.lock sebastianbergmann/phpunit#5576
• Consider adding a composer.lock file in the repository bobthecow/psysh#767
• Consider adding a composer.lock file in the repository phpro/grumphp#1095
• phpbench: init at 1.2.14 NixOS/nixpkgs#255253
• https://github.com/phpstan/phpstan-src/blob/1.11.x/composer.lock
• Adding composer.lock in VCS ? vimeo/psalm#10446

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 artefacts 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.

[jrfnl]

@drupol While I hear what you are saying, this project is not a good match for your suggestion.

Committing a composer.lock file is a really bad idea for projects which need to support a wide variety of PHP versions and hinders developers no end.

Also note that while a lot of the projects you mention have a wide range of external dependencies - in which case you could have a valid point -, that is not the case for this project, which has none, so the PHAR file is already 100% reproducible at any given time.

[drupol]

Thanks for your fast response.

As of today, the PHAR file is not reproducible (running sha256sum twice on 2 consecutive builds will produce 2 different hashes), simply because Box is not configured with the proper flags to create identical builds AND because the composer.lock file is missing.

But OK, my goal here is not to make the PHAR reproducible, but make sure that anybody running composer install can get the same vendor directory, bitwise identical.

Therefore, as a middle ground, would it be possible to reconsider? How about not committing the composer.lock file and exposing the composer.lock file you used to create and publish the PHAR file as an artefact?

[jrfnl]

But OK, my goal here is not to make the PHAR reproducible, but make sure that anybody running composer install can get the same vendor directory, bitwise identical.

Anybody running composer install for this project should get the right dependencies for the PHP version they are running on, which will be different depending on the contributor and the issues they are investigating.
And that is exactly as it should be and a committed composer.lock file would hinder that no end.

Anybody running composer install for a project using this package would never see any effects of this project having or not having a committed composer.lock file as the lock file of dependencies is not taken into account.

Also, it seems you only seem to know that you want to enforce some mythical idea which is counter-productive to the project, but don't actually seem to know why (you keep coming up with different reasons, none of them valid)

So, again: No.

[drupol]

I understand your concerns about maintaining flexibility across different PHP versions and ensuring that the project is accessible for various developmental explorations. It’s clear that you’ve given considerable thought to the best practices for your project's context, and I respect your perspective.

However, I'd like to clarify that my suggestions were made with the best intentions for the project's long-term reliability and the community's ease of use in mind. While I recognize that including a composer.lock file in the repository might not align with your vision for this project, my aim was to propose a solution that enhances consistency and predictability for end-users and contributors alike.

Given the points you've raised, I wish to address the notion of reproducibility not as a "mythical" idea but as a foundational principle in software development, especially in open-source projects. Reproducibility ensures that anyone, at any point in time, can build the software from source and obtain an identical outcome, which is crucial for debugging, security audits, and long-term maintenance. It's a practice endorsed by numerous projects to enhance trust, security, and collaboration among developers. By ensuring that every contributor and user can replicate builds and dependencies with precision, we lay the groundwork for a more robust and secure software ecosystem. This principle supports not just the immediate needs of developers but also facilitates a stable environment for future contributions and integrations.

Anyway, I'll be glad to discuss that matter lively with you! Cheers.

[jrfnl]

The "mythical" was in reference to your believe that a composer.lock file is a good idea for projects like this, not to the principle of reproducibility.

I understand your point about reproducibility, but it's just not a valid point in this case.

To repeat what I have already said before: this project does not have any runtime dependencies, so your point is null and void.

Also, PHP is not a pre-compiled language, so compiling is not necessary.
You can either choose to run from source checking out a commit/tag will give you the same files every time to the byte each time. No need to even run composer install --no-dev as there are no runtime dependencies.
Or you can choose to run from the PHAR file and use the signature to verify that it is the PHAR as released.

Anything else is searching for hypothetical problems which do not exist for this project.

Either way, to me, this discussion is closed.