Le 11/06/2014 04:30, Tim Starling a écrit :
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/ it has been proposed that we make a git clone of the MW core not be installable until $IP/vendor is populated somehow -- either by separately cloning the mediawiki/core/vendor project, or preferably by running composer to obtain dependencies.
I have suggested, as a compromise, to make the vendor directory be a submodule pointing to mediawiki/core/vendor. Then users can either run "git submodule update --init" to obtain dependencies, or they can omit submodule initialisation and instead run composer.
I would like to hear more comments on this.
Hello,
I would prefer us to avoid embedding third party libraries directly in core: - the repository is already big enough as it is (recently Chad proposed to drop history to shrink the repo). - we might be tempted to have local hack and forget to push them back to upstream
Assuming the above, we would require an extra step and I am fine with it. For people running mediawiki out of a git clone that should not be too much of an hassle, the rest of the user base uses the tarball or a package which could both embed all the third party libraries.
I do not think we should mix both system and should make a choice between git submodule and composer.
A rough comparison on top of my mind, should probably start up a formal RFC about it though they are probably some going on.
== git submodule ==
+ command already available + already used by Wikimedia to handle extensions dependencies in the wmf branches + let us review the code + ability to patch third parties - require to fully clone each repositories - version tracked by git sha1 in .gitmodules instead of a version number
== composer ==
+ generates autoloader entries + has a post install system which could be used to inject settings in LocalSettings.php + could be used to handle extensions dependencies - depends on upstream to incorporate our patches - needs to install composer - might not be used as-is on Wikimedia cluster
Before we make any decision, I would love to hear from Bryan Davis (he is on vacations this week) and Jeroen De Dauw who already put a lot of efforts on dependencies management.
cheers,