2020-12-17 Meeting notes Composer Support Initiative

Date

Dec 17, 2020

Participants

  • @Ruth Cheesley

  • @Nick Veenhof (Deactivated)

  • @Jan Linhart

  • @DavidCoutelle

Goals

  • Decide priorities

  • Plan our next steps

Discussion topics

Notes

Notes

  • Discussed the problem statement from Confluence

  • Confirmed that you will have a regular UI based installation and the option for a Composer based install if you want to - the GUI based installation will run the Composer tasks ‘under the hood’.

    • Combining the two is the biggest problem we are facing as we do not separate the plugins from core, and that the vendor folder is in the same folder as the application

    • If we want a zip file we need to have the vendor file in the same folder but Composer should be able to move it if that is desired.

    • How do we go from Zip based into Composer? Need to have a guide to help people as they will need to be able to do this

  • Plugins needs to be addressed first

    • Mautic Core in a core folder

      • Plugins in this folder ship with the core Mautic package

    • Everything else is generated by Composer

    • Requires the whole structure of Mautic to be changed - big changes

  • Discussed how the Marketplace will work - @Jan Linhart outlined the principles of there being a UI that pulls from Packagist. It would call the Composer commands to install those packages.

    • How do we allow that if Composer is not available on the server - would be restricted to the library

    • Should not be allowed if you have read only file systems - so would need to think how to do this.

      • Feature flag to disable the install - or even hide it entirely - if it is in an environment where installing should not happen.

        • Should show the composer install commands if people prefer to use the command line after seeing it in the folder

  • Challenges

    • Composer would wipe out everything so we need to change the structure to prevent that happening

    • Local.php - move it to the database as some file systems are not writeable (hacky things going on to work around it)

    • Plugin and theme discovery is difficult - it should be possible to look for the folders rather than pre-specify the locations

    • We are essentially moving from being a Symfony project to being a library

  • Need to brainstorm the folder structure and come to an agreement what it would be

    • Would have to be 4.0 but we can work on it now and get those decisions made

    • Need to think about shared hosting and make it configurable (default in the same folder but an option to move it)

    • How will we migrate people to the new structure

  • Documentation is going to be really important

  • @Nick Veenhof (Deactivated) suggested it will be tricky for folk with custom plugins as we do not have a differentiator between core/custom right now

  • We should start to decouple the plugins sooner rather than later - that could happen in a minor release

  • Composer plugin which will move the files to the right folder is used by most people who are using Composer at the moment

    • This could probably be ditched when we roll out this initiative because we tell based on the type where the files should be installed

  • Chunk down into projects/tasks and what needs to be done by when

    • Agree on the folder structure that we will use

    • Plugin / theme discovery

    • Plugin decoupling from core

  • Suggestion for structure by default (but we should have it discover the locations)

    • docroot/index.php
      Docroot/plugins
      Docroot/themes
      Docroot/core < - Core Mautic application
      Docroot/core/plugins < - Core plugins
      Docroot/core/themes < - Core themes (could also have a contrib and custom folder)
      Docroot/plugins/contrib < - Downloaded by composer
      Docroot/plugins/custom < - Self written code for this instance
      Docroot/config/ < - Configuration (user created)

  • @Jan Linhart suggested there should still be an option to allow folk to configure their settings to move some/all folders

  • Store the db config to a file (or docroot/config) by the application or the user - as soon as the application is installed the file becomes read only

  • Composer merge plugin - to combine two composer files - adds all the dependencies into one file from multiple composer files but it does not support Composer 2 to date

  • Do we want to adopt Composer 2?

    • Marketplace will not work in the GUI with Composer 1 as it is too slow

    • Do we support both and have a switch for things that do not support it?

    • We want to support 2 but we are blocked by Symfony 4 support due to a dependency that is required

  • Makes sense to base this work on Symfony 4

  • Nick’s project will need to be updated to support Composer 2 but he thinks that the changes should be fairly minimal

  • Nick needs some support with the plugin discovery side of thing from someone with Mautic experience - need to make a POC (maybe there is something in Symfony that could do this)

    • Plugins are configured by namespace within app/kernel

    • How does this work in Drupal? See if we can find contacts who worked on this in Drupal

  • Should create a POC

  • Packagist - we need to have some way we can test without using Packagist

    • Could decouple some of the plugins and use those to pull in with packagist

    • Would help to have some docs on how to decouple the plugins to help others do this

    • Can we use Acquia’s team to help with this?

  • We will work on Confluence and manage decisions/POC’s there.

Potential projects to chunk down

  1. Folder structure

  2. What plugins are with core

  3. Decoupling

  4. Zip to Composer

  5. Testing in different environments

Chat text:

00:04:45 Ruth Cheesley (she/her): https://mautic.atlassian.net/wiki/spaces/MI/pages/324337710
00:05:07 nickveenhof: https://docs.mautic.org/en/plugins/microsoft-dynamics-crm
00:22:27 nickveenhof: https://github.com/drupal/drupal
00:26:11 nickveenhof: https://github.com/nickveenhof/mautic-project/blob/3.x/composer.json#L96
00:27:09 Jan Linhart: https://github.com/mautic/composer-plugin
00:32:56 nickveenhof:
00:37:01 nickveenhof: docroot/index.php
00:37:06 nickveenhof: Docroot/plugins
00:37:08 nickveenhof: Docroot/themes
00:37:12 nickveenhof: Docroot/core
00:37:25 nickveenhof: Docroot/core/plugins
00:37:31 nickveenhof: Docroot/core/themes
00:37:47 nickveenhof: Docroot/plugins/contrib
00:37:52 nickveenhof: Docroot/plugins/custom
00:40:23 nickveenhof: Docroot/config/
01:02:53 nickveenhof: https://www.youtube.com/watch?v=qHaSCPi0324&ab_channel=DrupalAssociation
01:03:02 nickveenhof: https://www.drupal.org/about/strategic-initiatives/automatic-updates

Action items

Write up what is in-scope on Confluence @Ruth Cheesley will do this
Get some feedback on the proposed folder structure - start in a GDoc @Nick Veenhof (Deactivated) will do this
Reach out to @FlorianWessells for some input on how they do it in TYPO3 and ask if he can get involved with the initiative
Reach out to folk in the Drupal community who are involved with the Composer-ification project @Ruth Cheesley to do this

Decisions

  1. Work in Confluence
  2. We will support moving from Zip-based installation to Composer-based installations
  3. We will provide a migration path for existing instances
  4. We will only support Composer 2
  5. We will only support from Mautic 4 onwards