Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed PHAR builds support #770

Open
wants to merge 1 commit into
base: 8.9.x
Choose a base branch
from
Open

Conversation

Ocramius
Copy link
Member

@Ocramius Ocramius commented May 22, 2024

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.

nix flake

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.

composer.json, composer.lock and composer install

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:

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.

use a Dockerfile

This approach comes with the same downsides of .phar files, but:

  • tooling to scan for vulnerabilities inside docker images exists, 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"

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.

## `nix` flake

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.

## `composer.json`, `composer.lock` and `composer install`

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.

## use a `Dockerfile`

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"
@Ocramius
Copy link
Member Author

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, .phar should finally just go away.

@asgrim
Copy link
Member

asgrim commented May 23, 2024

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;

  • nix is still quite niche, so whilst it might be an acceptable solution for those already using nix, or for those "tempted" to use it, I don't think we should all-in on that solution
  • perhaps provide a baked Docker image (like Composer does) with a built phar already in it? That way, we can be clear about the environment that the phar was built with, and if you "extract" the phar from there into your own, you're basically "on your own". I know it doesn't 100% eliminate phar builds, but at least it helps one of the issues mentioned

Conversely to this proposal, an idea to keep phar around;

  • Keep the phar build, but run the phar build on EVERY build, not just releases. Save it as an artefact for the build. Then the only difference in a release build is taking the artefact and adding it to the release. At least then we get a sort of early warning system if the build may break.

@asgrim asgrim self-requested a review May 23, 2024 05:25
@drupol
Copy link
Contributor

drupol commented May 23, 2024

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 roave-backward-compatibility-check by running: nix run github:NixOS/nixpkgs#roave-backward-compatibility-check

Copy link

@GeeH GeeH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with everything said here. The overhead is not worth the benefit at this point.

@Slamdunk
Copy link

Slamdunk commented May 23, 2024

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.
To me it's even better than all the solutions proposed in #770 (comment), but I understand that it may be cumbersome to support for small tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants