Composer support

[jeffw16]

As per the initial specs doc I wrote last year, we need to add Composer support eventually

[yaronkoren]

The general view on adding Composer support seems to be roughly this:

• Canasta should include a volumed-in composer.local.json file, which starts out blank and is editable by the administrator (this is in fact already described in the documentation, even though it doesn't exist yet).
• composer.canasta.json should "include" composer.local.json, using the composer-merge plugin (created by Wikimedia developers!).
• Any files/directories that the two Composer files say to add to the vendor/ directory should get added to the standard vendor/ directory, with composer.local.json taking precedence if there's an overlap.
• Conversely, any files/directories that the two Composer files say to add to the extensions/ directory should get added to two different directories: canasta-extensions/ for composer.canasta.json, and user-exensions/ for composer.user.json. This may be the trickiest part to implement. (If in fact it's too tricky to do, another option is to simply send all of them to canasta-extensions/ - which may confuse admins, but it should still work.)

[olsonjaredm]

Agreed. Is it user-extensions or extensions in the latest? I lost track.

One use case is if an admin wants specific versions of given extensions that they know are compatible with their setup/environment. This could include extensions that are bundled in Canasta, but at versions different than the bundle. For this reason it makes sense to put the files in extensions as these take precedent over canasta-extensions.

composer update is invoked now in the Dockerfile for some deps. Does adding Composer support entail adding a Composer script that is instead invoked after container start, or should it continue to be in the Dockerfile?