Revert "Make it possible to install extensions using Composer"
authorOri.livneh <ori@wikimedia.org>
Sun, 11 May 2014 10:00:35 +0000 (10:00 +0000)
committerOri.livneh <ori@wikimedia.org>
Sun, 11 May 2014 11:33:05 +0000 (11:33 +0000)
commit9548f60e7a404ca5ef6aa03387b269dbbdd26f46
treeefffc29451a6fc8ddff6aed1d513a7b5c4b0608a
parentd8f3dd8f391512fe68712c4fef229e84fa797afb
Revert "Make it possible to install extensions using Composer"

This reverts commit d6e69d774.

MediaWiki extensions are by definition part of the MediaWiki software
ecosystem, and could therefore be managed using a specialized solution;
The same is not true of PHP packages at large: we're not in a position to
change how the PHP community at large manages dependencies. To the extent
that we have a choice, we should use interfaces like composer.json to
solve for the problem of integration with the outside world.

Change Ib125bea00 made the opposite choice, compromising our ability to
express how MediaWiki relates to external software components in exchange
for superficial gains in convenience of managing MediaWiki extensions.
(I consider the gains superficial because they do not leverage the fact
that extensions share MediaWiki's code -- a property that should be
exploited to provide an extension management solution that is
MediaWiki-aware, providing, for example, a uniform configuration
management interface.)

The cost of that change are manifest in bug 64597: we lost the ability to
express a dependency on PHPUnit in the way that the PHPUnit upstream
recommends.

The problem that change  Ib125bea00 set out to solve is that modifying
composer.json to express dependencies on extensions means having a local
diff that conflicts with the code in version control. This issue is
actually discussed by the Composer documentation. In short, Composer's
developers recommend that if your production environment uses a cvs to
version code, you should maintain your own clone of the upstream
repository and version your composer.json that way. More detailed
discussion of these issues can be found at
<https://getcomposer.org/doc/05-repositories.md#vcs> and
<https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>.
I also note that the Composer documentation makes many references
to monolog as an exemplary Composer project, and it too maintains a
composer.json in the repository root.

Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
composer-example.json [deleted file]
composer.json [new file with mode: 0644]