Remove support for PHAR releases

[Ocramius]

PHAR releases are generally problematic, because:

1. we don't automate them
2. the dependencies within the phar are frozen to a set that could easily be updated, and so issues could be reported here instead of where they should be reported (upstream)
3. traces are completely different/complex

Overall, my suggestion is therefore to:

1. get rid of the .phar release
2. clearly endorse an approach on how to install and run maglnet/composer-require-checker independently from project sources

I'll probably start scrapping .phar releases on my own projects in the short-term future too.

Fixes #238

[asgrim]

FWIW, if "incompatible dependencies" is an issue that causes you to need to use Phar, you can usually workaround with something like the following GH action:

      - name: "Require Roave/BackwardCompatibilityCheck"
        run: "composer require --no-update --no-interaction --prefer-dist --prefer-stable --dev roave/backward-compatibility-check"
      - name: "Composer update with new requirements"
        run: "composer update --no-interaction --prefer-dist --prefer-stable"
      - name: "Check for BC breaks"
        run: "vendor/bin/roave-backward-compatibility-check --format=markdown"

[Ocramius]

Also:

mkdir /tmp/my-tool
cd /tmp/my-tool
composer require <the-tool>

Good enough

[OskarStark]

Until we have a decision here, @maglnet can you please provide the PHAR file for 3.2.0 release? Thanks 🙏

[maglnet]

@OskarStark Sorry, it's now attached to the release.

[OskarStark]

No problem

Thanks you very much 💥

[jakzal]

Just noticed 3.3.0 phar is also missing as well as the gpg key:

$ phive install --target ./tools/ composer-require-checker
Warning:  composer-require-checker 3.3.0: No downloadable PHAR
Downloading https://github.com/maglnet/ComposerRequireChecker/releases/download/3.2.0/composer-require-checker.phar
Downloading https://github.com/maglnet/ComposerRequireChecker/releases/download/3.2.0/composer-require-checker.phar.asc
Downloading key 033E5F8D801A2F8D
Trying to connect to keys.openpgp.org (37.218.245.50)
Trying to connect to keys.openpgp.org (2a00:c6c0::154:1:0:0:1)
Error:    Request failed:  (while requesting https://keys.openpgp.org/pks/lookup?op=get&options=mr&search=0x033E5F8D801A2F8D)
Warning:  Failed with error code 404: Key not found on keyserver
Trying to connect to keyserver.ubuntu.com (162.213.33.8)
Trying to connect to keyserver.ubuntu.com (162.213.33.9)
Warning:  Failed with error code 404: Key not found on keyserver
Error:    PublicKey 033E5F8D801A2F8D not found on key servers

[DanielBadura]

Only @maglnet can create atm a new signed phar as far as i know. So maybe he can attach it again like for the 3.2.0 release.

[ThomasLandauer]

@maglnet Please create a PHAR for 3.3.0.
At https://github.com/maglnet/ComposerRequireChecker/#phar-file-preferred phar is still the recommended way of installing - so if you're not releasing it regularly anymore (see same comment for 3.2.0 above), this should be deleted from README.

[maglnet]

@ThomasLandauer the phar file is attached now. You're right, the preferred way should either be changed or the phar should be created automatically.

[ThomasLandauer]

When doing phive update, the new phar is downloaded, but then it fails with:

Failed with error code 6: DNS Problem: Did not find any IP for hostname "hkps.pool.sks-keyservers.net"

I don't know who's in charge of this URL, though ;-)

[maglnet]

Well there's a list of public key servers provided with phive, if the server is gone, maybe it needs to be removed from the list?
https://github.com/phar-io/phive/blob/master/conf/pgp-keyservers.php

[Slamdunk]

@ThomasLandauer the phar file is attached now.

The current 3.3.0 PHAR is broken for Linux: #281

[Ocramius]

Adding more gasoline to the fire:

• Error parsing \Doctrine\ODM\MongoDB\Aggregation\Stage\GraphLookup\Match with php8 #283 reported a bug that is due to an outdated dependency in the .phar
• PHAR 3.3.0 has \r char that breaks tool under Linux #281 reports broken .phar
• broken phar release #140 reports a bug that only occurs in a .phar release

I think the waste of time is becoming quite evident.

[theseer]

While I admit I'm not using this tool myself, I fully disagree with the idea of this issue and just want to contribute my PoV. Maybe it's helpful - maybe not, then feel free to ignore it.

Your points against phar are:

1. we don't automate them

This is hardly a problem of using phars as a concept but rather a lack of automation. If there's any interest, I can offer help to automate building phars.

2. the dependencies within the phar are frozen to a set that could easily be updated, and so issues could be reported here instead of where they should be reported (upstream)

To me, this is completely backwards:

It's not a downside at all but very much an upside. Instead of not knowing what arbitrary set of versions of dependencies may or may not have been installed, with a phar I do have a known stable set I can also reproduce issues with.

I also disagree with the notion that issues could (let alone should) be reported upstream: If I use a tool and it doesn't work, I hardly care if the issue is with a library it uses or within the tool itself. At least I would report a bug with the tool vendor. The tool vendor now either has to support a wide variety of versions of a library with various types of workarounds until the upstream issue is fixed. But then what? Update the minimum version in the composer.json? How do you do that without making a new release of the tool? And how would that then be different from releasing a new phar?

To me, when a software is released, it's a packaged thing. If my software requires 3rd party libraries, with a release of my software, I consider the currently tested set of them part of my software package. I explicitly do not want any user to be required to deal with them.

To me, phar is the very answer to that and not the problem.

3. traces are completely different/complex

Unless you run PHP-Scoper before packaging, I fail to see how that can be.

HTH :-)

[maglnet]

Since today, the release process, including the creation of phar files and signing, is completely automated.

As long as there is no other easy "standard" to install tools separately, I'd prefer to not drop the phar releases for now.
Nevertheless, if there's any way for easily shipping tools, let me know.

For details see #316 #317

[OskarStark]

Thanks a lot

[samdark]

I don't think it's a good idea. It's way better to use PHARs by default to avoid dependency issues.

[Ocramius]

You get my dependencies, not those that are fitting your system and lockfile, and you also get the security issues of all the dependencies that I had at release time 😋

[samdark]

#561