Conversation
|
I should add that I'm removing the tooling also because I'm fed up with coming back to it every few months and finding it broken: given multiple better tools exist, |
|
Composer is literally the only phar I use I think, but I know some people do use phar for tools like this. I'm generally okay with this, but with caveat;
Conversely to this proposal, an idea to keep phar around;
|
|
I couldn't agree more with this! PHARs are very convenient, but in 2024 if they cannot be reproduced, it's critical. Therefore, my contribution to this: NixOS/nixpkgs#313907 Once this will be merged, anybody running Nix will have access to |
GeeH
left a comment
There was a problem hiding this comment.
I agree with everything said here. The overhead is not worth the benefit at this point.
|
At first I've been hesitant about PHPStan's deployment style, but now I like and endorse it: provide a PHAR as a composer package. |
This also removes all tooling around PHAR builds. While PHARs have some use for some community members, PHARs: * do not come with a runtime/environment * are inherently unsafe, because (even if signed) you are relying on packages downloaded and installed by maintainer who created the `.phar` file * do not match your system requirements, which may be misaligned with bundled libraries, since you are relying on the maintainer's ( @Roave / @Ocramius ) selected set of dependencies There are various ways to install PHP tools that are way better than PHAR, and that are to be endorsed instead. See https://nixos.wiki/wiki/flakes Nix flakes are completely immutable, stable, fully reproducible, customizable, and come with a full supply chain traceability of all dependencies. For maximum stability in your builds, use a nix flake. Patches are welcome to turn this package into a nix flake in itself. If you have an environment, and you want to install this package into it, generate a `composer.json` and `composer.lock` at a specific location: ```sh cd path/to/tools composer require roave/backward-compatibility-check git add composer.json git add composer.lock git commit -m "Managing own locked version of \`roave/backward-compatibility-check\`" ``` You can then `composer install` from that directory at any time, and run `./path/to/tools/vendor/bin/roave-backward-compatibility-check`. `composer install` will verify that your environment is suited for installation. This approach comes with the same downsides of `.phar` files, but: * tooling to scan for vulnerabilities inside docker images exist, and is very much growing * a docker image comes with the runtime to execute `roave/backward-compatibility-check`, and you can even run the full test suite before baking the image and calling it "compatible"
53a1cb5 to
d19a3b3
Compare
|
Merging here: will stick to this project being a source distribution. Any binary distribution (with the security implications thereof) is not to be handled in this repository. |
This also removes all tooling around PHAR builds.
While PHARs have some use for some community members, PHARs:
.pharfileThere are various ways to install PHP tools that are way better than PHAR, and that are to be endorsed instead.
nixflakeSee https://nixos.wiki/wiki/flakes
Nix flakes are completely immutable, stable, fully reproducible, customizable, and come with a full supply chain traceability of all dependencies.
For maximum stability in your builds, use a nix flake. Patches are welcome to turn this package into a nix flake in itself.
composer.json,composer.lockandcomposer installIf you have an environment, and you want to install this package into it, generate a
composer.jsonandcomposer.lockat a specific location:You can then
composer installfrom that directory at any time, and run./path/to/tools/vendor/bin/roave-backward-compatibility-check.composer installwill verify that your environment is suited for installation.use a
DockerfileThis approach comes with the same downsides of
.pharfiles, but:roave/backward-compatibility-check, and you can even run the full test suite before baking the image and calling it "compatible"