Le 25/07/2014 11:08, Daniel Kinzler a écrit :
This is about whether it's OK for MediaWiki core
to depend on other PHP
libraries, and how to manage such dependencies.
Background: A while back, I proposed a simple class for assertions to be added
to core[1]. It was then suggested[2] that this could be placed in a separate
component, which could then be re-used by others via composer. Since the
assertions are very little code and nicely self-contained, this should be easy
to do.
However, if we want to use these in MediaWiki core, core would now depend on the
assertion component. That means that either MediaWiki would require installation
via Composer, or we have to bundle the library in some other way.
What's the best practice for this kind of thing? Shall we just make the
assertion repo an git submodule, and then pull and bundle it when making tarball
releases? Should we switch the generation of tarballs to using composer? Or
should we require composer based installs in the future? Are there other options?
Hello Daniel,
The idea is to rely on the git repository mediawiki/core/vendor (that is
going to be renamed as mediawiki/vendor). It contains a composer.json
file and is supposed to contain the download code.
On production we would just clone mediawiki/vendor with the same branch
that mediawiki/core is using. Much like we are already doing with
extensions.
For continuous integration purposes, that is a bit more challenging. I
have worked on a client that let us clone multiple repositories and make
sure they all use the branch of the patch being tested with graceful
fallback to master.
So if one push a change to mediawiki/vendor 1.24wmf25 , the script would
clone mediawiki/core and attempt to checkout 1.24wmf25 then run the
tests with the resulting code.
I still have to figure out a bunch of details such as how to clone so
many repositories on Jenkins slaves for each job we have. But that is
being worked on for sure.
cheers,
--
Antoine "hashar" Musso