Drop gpm. Use composer (+ possibly plugins)

[drzraf]

Sooner or later, most mainstream PHP framework/CMS dropped their custom installer. Be it bundles installation for Symfony or drush-make at Drupal.

They didn't dropped their respective command line tool, but all the rest related to dependency-resolution/download/extraction/installation and pre|post-install|update scripts where standardized using composer features. And in case of particular needs (eg: Symfony flex installation recipes) this has gone through a composer plugin.

I went over previous discussion ¹ and still fail to see any current or future usecase for GPM that wouldn't be solved in a better way by composer + plugins (let's recall that composer plugins can be referenced as dependencies of the original composer.json file).

Looking at gpm list, all of the features and underlying concepts are provided by composer : distribution, repositories, stability. A tarball download isn't worth NIH since it can be done by anyone using an alias for curl | tar -C.

https://getgrav.org/ makes a point about sophisticated Package Manager to make it super flexible. I tend to disagree. composer is way more flexible and sophisticated (and well-known). And if projects from mediawiki to WordPress/bedrock can use it, I don't see what would make Grav so specific it could not do it.

Let's take the risk to show some actual use-case that gpm fails to address:

• I want to install a plugin from git: composer --prefer-source or preferred-install key
• I want to have a base plugin set and customize some installation: A set composer-*.json requiring wikimedia/composer-merge-plugin
• I want a default template installation: post-root-package-install
• I want a specific plugin post-install processing, assets downloading, ...: script: { "post-install-cmd": { ... } }
• I want something more standard in terms of installation solution w.r.t. other CMS: composer/installers and installer-paths
• I want private repositories: use the repositories key etc...etc...etc...

Granted: composer is slow (not so true anymore since composer 2.0) and can't extract a tarball given its URL on the command-line and I'm sure one may find workarounds for each above use-cases using GPM. Still, Grav is great but it's worth focusing of what it best does. The PHP package management problem has already been solved by existing mainstream tools long ago.

¹ https://discourse.getgrav.org/t/why-gpm-and-not-composer/3124/4

[rhukster]

Composer has come a long way since we started Grav and created GPM. It's definitely more capable now, and there is a fair bit of overlap, and of course composer has a huge amount of great functionality. However, there are things we do in GPM that are simply not possible in Composer. Things like support for handling license keys (currently unused, but we plan on utilizing this support soon).

We'll probably take another look at Composer or at least 'parts' of composer to have better support for dependencies with Grav 2.0, but for now in Grav 1.x there's no point making such a large and potentially impactful change.

[mahagr]

To make this to happen, we need two things:

1) plugins must start using composer.json with all the required fields 2) we need likely to add our own packagist compatible listing as we need support for our own directory