php / pie

The PHP Installer for Extensions
176 stars 3 forks source link

Replace legacy polyfills, unbound php upper bound #51

Open nicolas-grekas opened 2 hours ago

nicolas-grekas commented 2 hours ago

I suggest the following patch to composer.json:

Unlocking the upper bound of PHP to give back control to end users about where they want to run the tool. Replacing some polyfills that don't need to be installed, but would be otherwise.

--- a/composer.json
+++ b/composer.json
@@ -26,7 +26,7 @@
         }
     ],
     "require": {
-        "php": "8.1.*||8.2.*||8.3.*",
+        "php": ">=8.1",
         "ext-zip": "*",
         "composer/composer": "dev-main@dev",
         "guzzlehttp/guzzle": "^7.8",
@@ -44,6 +44,11 @@
         "psalm/plugin-phpunit": "^0.18.4",
         "vimeo/psalm": "^5.22"
     },
+    "replace": {
+        "symfony/polyfill-php81": "*",
+        "symfony/polyfill-php80": "*",
+        "symfony/polyfill-php73": "*"
+    },
     "config": {
         "sort-packages": true,
         "preferred-install": "dist",
asgrim commented 2 hours ago

We cannot claim to support PHP 8.4 yet (that is work in progress still - see #32), so this is a no-go really; it does not exist in its final form yet yet, so we cannot possibly claim support for it. If people want to test it without explicit support, it is already possible to use composer install --ignore-platform-req=php+

nicolas-grekas commented 1 hour ago

As long as bug fixes are released for PHP 8.4, the declaration would still be correct. Any OSS license explains that the software is provided "as is", without even any promise of a purpose. A composer.json file is not the place for more restrictive claims.

composer install --ignore-platform-req=php+

yes, that's a workaround though, around authors that have too restrictive policies ;)

Note that while writing this comment, I realized that this repo has no license terms anywhere. Something to fix I suppose.

asgrim commented 48 minutes ago

As long as bug fixes are released for PHP 8.4, the declaration would still be correct.

And until such time, the declaration is wrong, and all current releases are possible to install but actually be broken, with no way of retrospectively fixing those already released versions in the wild (short of deleting the tags or other destructive methods). For example: a breaking change in PHP 9.0 for example may cause all older versions to stop working for some reason; if you subsequently exclude PHP 9 from a later release due to needing extensive changes to support a new PHP version, it doesn't matter - the already released versions make a claim they are compatible with PHP 9.0, but they are not, in actual fact.

Any OSS license explains that the software is provided "as is", without even any promise of a purpose.

Quite - and I would use this same point to encourage those who want to use it in ways they want to to use:

composer install --ignore-platform-req=php+

as already proposed.

yes, that's a workaround though, around authors that have too restrictive policies ;)

The restrictive policy is intentional; dependencies maybe declared on a project to claim compatibility, with at least some vague consensus/expectation that the author(s) have actually tested the software with the dependencies claimed. A library who claims they are compatible with unreleased future versions (such as PHP 9.0 or beyond) cannot possibly be guaranteeing that.

One middle ground perhaps, is to use the semver token (i.e. ^8.1); and whilst PHP itself does not actually use semver, would go half way in solving the above issues resulting from "major" changes in the language; which typically PHP itself tries to reserve for major version bumps (I like to think of it as semver-"ish"). I would settle for ^8.1 as a middle ground (even though I have seen issues with even this style of declaration in libraries, as it is extremely common), but I think it is dangerous to claim compatibility with ALL possible future versions of PHP ever.

Note that while writing this comment, I realized that this repo has no license terms anywhere. Something to fix I suppose.

That is a very good point, and I shall raise a separate discussion about which license (I'd assume it would be PHP 3.01, but will check). Update: see #52 for that