Within CirrusSearch we are in the progress of updating to use elasticsearch 5.x. This has a few changes to the API, and necessitates a new version of the Elastica support library. Elastica now depends on php 5.6 (but doesn't use any special features, they are simply only supporting non-EOL php versions). This specifically becomes an issue because jenkins tests the mediawiki/vendor repo with 5.5.9, and as such the tests reject any dependency that requires >= 5.6.0.
There are a few options for handling this but i wanted to see what other people think:
* Fork the library, publish it under wikimedia/elastica, and change the minimum version to 5.5.x This is a bit of a pain, but accomplishes the goal * Fake the platform[1] in mediawiki/vendor composer.json. This is sub-optimal because it applies to everything, not just a single dependency. I could see us accidentally pulling in code that will not meet our requirements. * We could use `--ignore-platform-reqs` on the command line, but this has the same problem as previously * We could hope external developers will answer our pleas for supporting EOL php, but i've emailed the elastica dev and they arn't interested in supporting EOL PHP.
Barring other suggestions, I'm probably going to fork and re-publish Elastica via the wikimedia github.
On Mon, Jan 23, 2017 at 12:29 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
- Fork the library, publish it under wikimedia/elastica, and change the
minimum version to 5.5.x This is a bit of a pain, but accomplishes the goal
You could also fork the package definition (ie. use a hand-maintained package file instead of packagist, but still refer to the upstream elastica repo in that file), that's less effort to maintain. OTOH unless they have a policy of keeping B/C with PHP 5.5, you'll probably have to fork the code sooner or later anyway.
On Mon, Jan 23, 2017 at 3:19 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Jan 23, 2017 at 12:29 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
- Fork the library, publish it under wikimedia/elastica, and change the
minimum version to 5.5.x This is a bit of a pain, but accomplishes the
goal
You could also fork the package definition (ie. use a hand-maintained package file instead of packagist, but still refer to the upstream elastica repo in that file), that's less effort to maintain. OTOH unless they have a policy of keeping B/C with PHP 5.5, you'll probably have to fork the code sooner or later anyway.
That does sound a little easier, although if i'm going to bite the bullet might as well go all the way. I'll be creating this repo tomorrow and getting everything put together. Should be relatively easy i think, although it means we're on the hook for pushing future changes and making sure they are 5.5 compatible.
It seems i could create the repo as either of these: * mediawiki/vendor/elastica? * mediawiki/extensions/Elastica/elastica
Will probably do the first, unless someone has a good reason not to.
_______________________________________________
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jan 23, 2017 at 3:29 PM, Erik Bernhardson < ebernhardson@wikimedia.org> wrote:
There are a few options for handling this but i wanted to see what other people think:
- Fork the library, publish it under wikimedia/elastica, and change the
minimum version to 5.5.x This is a bit of a pain, but accomplishes the goal
- Fake the platform[1] in mediawiki/vendor composer.json. This is
sub-optimal because it applies to everything, not just a single dependency. I could see us accidentally pulling in code that will not meet our requirements.
- We could use `--ignore-platform-reqs` on the command line, but this has
the same problem as previously
- We could hope external developers will answer our pleas for supporting
EOL php, but i've emailed the elastica dev and they arn't interested in supporting EOL PHP.
There's also the "bump MediaWiki's requirement to 5.6" option. ;)
wikitech-l@lists.wikimedia.org