> In the development community we are all easily competent enough to
> upgrade by the mix of using update db scripts, and applying diffs etc.
> Then manually specifying and extra plugins/deps in the
> composer.json. However the wider public aren't quite so competent. As
> such scripts such as phpBB use update scripts which apply the diffs
> and database updates. The problem is that these scripts are used as
> applications, not libs (like they would be when used by the
> development community).

> These scripts quite often have extra plugins/extensions/styles etc.
> that are installed. Composer could make installing plugins so much
> easier, however the problem we come across is how to manage those
> plugins. To add them having to edit the composer.json and then update
> the composer.lock is fine (although something db based would be
> more preferable as you cant always edit the file), except when it
> comes to updating. If we update the deps in the application, then part
> of the diff will be the changes to the composer.json & composer.lock.
> This will then conflict if any plugins have been installed on lines
> such as the hash which could confuse some end users and they won't
> know how to handle it.

> As such a cleaner solution would be to either allow having a second
> composer.json (called custom_libs.json or similar) which can handle
> the plugins. Then have a separate custom_libs.lock file for the
> plugins. However this creates a problem as it means a plugin cannot
> require certain versions of the application.

> Another solution could be the ability to handle requirements through
> two tables in a database (one holding the repos as they would be in
> the .json, the other being as it would be in the .lock) in addition to
> a composer.json/composer.lock which will manage any settings (minimum
> stability etc.) as well as any deps if they choose to have it there.
> Having the login information in a composer_login.json including the
> login information.

> Thoughts?