dev/core#6550 Update civix composer, permit php8+

[eileenmcnaughton]

This removes the restriction that civix be compiled on php7.4 and permits later symfony versions

Perhaps we still want a php version? However the current code would not run on php7.4 as it has str_contains and no php8.0 polyfill....

This requires #441 but the reverse is not true

see https://lab.civicrm.org/dev/core/-/work_items/6550

@totten

[totten]

However the current code would not run on php7.4 as it has str_contains and no php8.0 polyfill....

That doesn't seem right, for a couple reasons.

• composer info|grep poly shows:

  symfony/polyfill-ctype            1.23.0 Symfony polyfill for ctype functions
  symfony/polyfill-intl-grapheme    1.31.0 Symfony polyfill for intl's grapheme_* functions
  symfony/polyfill-intl-normalizer  1.31.0 Symfony polyfill for intl's Normalizer class and related functions
  symfony/polyfill-mbstring         1.22.1 Symfony polyfill for the Mbstring extension
  symfony/polyfill-php73            1.23.0 Symfony polyfill backporting some PHP 7.3+ features to lower PHP versions
  symfony/polyfill-php80            1.33.0 Symfony polyfill backporting some PHP 8.0+ features to lower PHP versions
  

• The only thing in civix using str_contains() is ConvertEntityCommand. Before doing its logic, this command boots CiviCRM... which would also load a copy of the polyfill...

This removes the restriction that civix be compiled on php7.4 and permits later symfony versions

This confused me, because...

• As a factual matter, the compilation step for civix is actually running on PHP 8.2. (The box.phar compiler requires PHP 8.2.)
• The setting config.platform.php==7.4 ensures that composer update and composer.lock continue to respect PHP 7.4 as the minimum. (If you don't have that, then running composer update on a random devbox... with a random PHP version... will rewrite composer.lock in a way that breaks PHP 7.4.)
• The version of symfony/filesystem (etc) should work fine in php74-php84 (and probably php85, iirc?). We use this composer.json and composer.lock for CI tests with several versions of PHP.

see https://lab.civicrm.org/dev/core/-/work_items/6550

Added notes over there. TLDR:

• It sounds like you're mixing two things that are both known to be risky -- using civix (with independent vendor/ and without PHAR/prefixing) and also using an extension (with independent vendor/ and without PHAR/prefixing) -- and they have collided in this case. (But the collision isn't about civix -- you could equally get the same collision with two extensions, without invoking civix.)
• If you have to keep the extension as-is, then I suggest improving the local workflow for civix.git=>civix.phar (e.g. use watchexec or File Watcher to build the PHAR automatically).

---

I think it's OK to relax the Symfony constraints (assuming the versions work). That doesn't interfere with the mainline/PHAR-oriented development of civix.

But dropping the config.platform.php==7.4 option would make it harder to maintain composer.lock for the mainline/PHAR-oriented development of civix.

[totten]

Closing as it failed tests, was a bit too aggressive, and is is now conflicted.

But a narrower PR (which just allows newer Symfony) could be useful for source-based deployments, eg

1. Allow developers who Install civix.git (source) as project tool (composer) in more projects/environments
2. Allow developers who Install civix.git (source) as standalone tool (Linux/BSD/macOS) to beta-test with newer Symfony.