[Extensions] Install extensions using composer

[Guite]

Depends on #3644

Use composer for installing extensions during runtime.

We could also use our extension library as a composer repository then and/or use packagist. Thus this would also solve #909 See also https://github.com/composer/satis

Example: Contao composer client (German manual). Example: Drupal composer manager

• [ ] POC for PHP-driven runtime executions
  • [x] Evaluations
    • [ ] Composer PHP docs
      • [ ] https://github.com/composer/composer/blob/master/doc/03-cli.md#depends
      • [ ] https://github.com/composer/composer/blob/master/doc/03-cli.md#prohibits
    • [ ] Composer PHP API
    • [ ] PageKit example
  • [x] Preparation: Read core dependencies out of composer folder / installed.json
  • [ ] Module installations and updates
    • [ ] Read core dependencies and merge with module dependencies
    • [ ] Install without changing core dep versions
    • [ ] If core dep versions would be changed the module can not be installed
  • [ ] Core updates
    • [ ] Set all modules to inactive whose dependencies conflict with updated core dependencies
• [ ] Tests
  • [ ] Install module with dependency to Symfony bundle
  • [ ] Uninstall module with dependency to Symfony bundle
  • [ ] Install module with dependency to other module
  • [ ] Uninstall module with dependency to other module
  • [ ] Conflict
• [ ] Further aspects
  • [ ] Rewrite our current extensions management.
  • [ ] Unify handling of modules and themes.
  • [ ] Also think about handling translations.
  • [ ] Handle legacy components

[rallek]

can we use this to add also language packs? Including language packs for modules and themes?

[craigh]

includes investigating creating our own "Packagist Channel"

• https://www.drupal.org/node/2718229
• https://packagist.drupal-composer.org/packages/drupal/channel
• https://packagist.drupal-composer.org/explore/
• http://drupal-composer.org

[discordier]

As @Guite contacted me via mail on this issue for feedback how we did this for Contao, I'll add some relevant links here.

• Our base for running composer: tenside (note that only core and core-bundle are up to date as we are still evaluating our specific manager).
• Our specific phar-application for using it in the Contao context: contao-manager
• Our vendor specific application for automated provisioning: contao/managed-edition
• Our vendor specific bundle in automated provisioned application: contao/manager-bundle

We also have our intermediate legacy-packagist installation running which is a direct gateway to our old extension repository during the transition phase until we decommission the old repository.

We would love to have others jump up on the same train using tenside as we also have only limited man-power, so let's join forces.

[craigh]

@discordier thank you so much for your comment and for the information. You are obviously much further ahead in this regard than we. I don't understand most of what you have here and it will take me much time to get up to speed. Perhaps @Guite understands quicker than me. I would love to work together as we also have VERY limited manpower but I'm afraid I will not be much help to begin with. Maybe sometime we can chat (slack?) and you can educate me more quickly. thanks!

[discordier]

I'm not that fond of slack as it is a pain for unpaid accounts (which is what most OSS projects are having). Feel free to contact me on freenode in #contao.de (user xtra) or on our mumble server mumble://mumble.c-c-a.org:62492

[craigh]

https://medium.com/@fabpot/fabien-potencier-4574622d6a7e

[Guite]

Some additional notes @discordier provided me by mail:

To handle the required time of a potentially long-running "composer update" the actual composer task is spawned as a sub shell from the web request. This requires proc_open() and similar methods though. For Contao it already works quite well despite some edge case problems with "exotic" servers.

The Contao Composer Client consists of two projects:

1. The GUI which is 100% Contao specific, but only provides the frontend.
2. The plugin which does the system integration (Contao 3 specific).

For Contao 4 which is a 100% native Symfony application this is overhauled: the client is decoupled from the backend there. For this the "contao-manager" is built which contains the Contao-specific encapsulation and Composer automation.

"tenside" is the basis for this automation and is independently developed to make it usable also for other projects.

[Guite]

As this will probably target a new major core version we should also consider incorporating Symfony Flex into the strategy as this helps with automated configuration of native Symfony bundles.

[Guite]

Possibly related: https://github.com/symfony/config/blob/master/Resource/ComposerResource.php

[craigh]

refs #3517

[Guite]

Closing as we are just using Composer and Flex (without any UI) in 4.0 - just back to the default way as it works in Symfony as well. Refs https://github.com/zikula/core/blob/main/ZIKULA-4.0.md