wiki.techinc.nl/composer.json

116 lines
3.3 KiB
JSON
Raw Normal View History

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
2014-05-11 10:00:35 +00:00
{
"name": "mediawiki/core",
"description": "Free software wiki application developed by the Wikimedia Foundation and others",
"keywords": ["mediawiki", "wiki"],
"homepage": "https://www.mediawiki.org/",
"authors": [
{
"name": "MediaWiki Community",
"homepage": "https://www.mediawiki.org/wiki/Special:Version/Credits"
}
],
"license": "GPL-2.0+",
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
2014-05-11 10:00:35 +00:00
"support": {
"issues": "https://bugs.mediawiki.org/",
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
2014-05-11 10:00:35 +00:00
"irc": "irc://irc.freenode.net/mediawiki",
"wiki": "https://www.mediawiki.org/"
},
"require": {
"composer/semver": "1.4.2",
"cssjanus/cssjanus": "1.1.3",
"ext-ctype": "*",
"ext-iconv": "*",
"ext-json": "*",
"ext-mbstring": "*",
"ext-xml": "*",
"liuggio/statsd-php-client": "1.0.18",
"mediawiki/at-ease": "1.1.0",
"oojs/oojs-ui": "0.20.2",
"oyejorge/less.php": "1.7.0.13",
"php": ">=5.5.9",
"psr/log": "1.0.2",
"wikimedia/assert": "0.2.2",
"wikimedia/base-convert": "1.0.1",
"wikimedia/cdb": "1.4.1",
"wikimedia/cldr-plural-rule-parser": "1.0.0",
"wikimedia/composer-merge-plugin": "1.4.0",
"wikimedia/html-formatter": "1.0.1",
"wikimedia/ip-set": "1.1.0",
"wikimedia/php-session-serializer": "1.0.4",
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
"wikimedia/relpath": "1.0.3",
"wikimedia/remex-html": "1.0.1",
"wikimedia/running-stat": "1.1.0",
"wikimedia/scoped-callback": "1.0.0",
"wikimedia/utfnormal": "1.1.0",
"wikimedia/timestamp": "1.0.0",
"wikimedia/wait-condition-loop": "1.0.1",
"wikimedia/wrappedstring": "2.2.0",
"zordius/lightncandy": "0.23"
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
2014-05-11 10:00:35 +00:00
},
"require-dev": {
"composer/spdx-licenses": "1.1.4",
"jakub-onderka/php-parallel-lint": "0.9.2",
"justinrainbow/json-schema": "~3.0",
"mediawiki/mediawiki-codesniffer": "0.7.2",
"jetbrains/phpstorm-stubs": "dev-master#1b9906084d6635456fcf3f3a01f0d7d5b99a578a",
"monolog/monolog": "~1.22.1",
"nikic/php-parser": "2.1.0",
"nmred/kafka-php": "0.1.5",
"phpunit/phpunit": "4.8.35",
"wikimedia/avro": "1.7.7",
"hamcrest/hamcrest-php": "^2.0",
Drop in replacement of eval.php based on psysh eval.php is meant to eval() commands in MediaWiki global scope. We had at least a couple attempts to move it to a regular Maintenance script. As noted on the revert commit b475e930 r54839, using a Maintenance script drop us in the callee function scope instead of the global scope which is a hard requirement. http://psysh.org/ is a Read-Eval-Print-Loop with color highlight, modern code and more. Add maintenance/shell.php script as MediaWikiShell class. Passing command from stdin is supported. Execution is forked for graceful handling of PHP fatal errors. Colors!! Support the undocumented '-d' arguments from eval.php: 0 set $wgDebugLogFile to stdout. Eval.php used /dev/stdout, make it php://stdout in the new script. 1 additionally set DBO_DEBUG on all the database load balancer servers PHP globals have to be whitelisted which is not supported out of the box by Psy. Upon request, the author of PsySh, Justin Hileman, kindly provided a pass to inject globals (with the exceptions of super globals). He agreed for code reuse: https://github.com/bobthecow/psysh/issues/353 The code was added to maintenance/CodeCleanerGlobalsPass.inc Note that this is not a perfect simulation of global scope (but pretty close): variables declared in the shell which did not exist before won't be global unless the 'global' keword is used. Example usage: $ php maintenance/shell.php >>> $wgFullyInitialised => true >>> $hashar = User::newFromName( 'hashar' ) => User {#274 +mId: null, +mName: "Hashar", ... >>> ls --long --all $h <descriptive output of all object properties/methods> Bug: T117661 Signed-off-by: Justin Hileman <justin@justinhileman.info> Signed-off-by: Gergő Tisza <tgr.huwiki@gmail.com> Change-Id: I3d6d42e138d3cc4a0aaafdd7f5f97cb17d8b8cb3
2017-01-25 22:29:40 +00:00
"wmde/hamcrest-html-matchers": "^0.1.0",
"psy/psysh": "0.8.3"
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
2014-05-11 10:00:35 +00:00
},
"suggest": {
"ext-apc": "Local data and opcode cache",
"ext-curl": "Improved http communication abilities",
"ext-fileinfo": "Improved mime magic detection",
"ext-intl": "ICU integration",
"ext-wikidiff2": "Diff accelerator",
"monolog/monolog": "Flexible debug logging system",
Produce monolog messages through kafka+avro This allows a logging channel to be configured to write directly to kafka. Logs can be serialized either to json blobs or the more compact apache avro format. The Kafka handler for monolog needs a list of one of more kafka servers to query cluster metadata from. This should be able to use any monolog formatter, although some like JsonFormatter require you to disable formatBatch as Kafka protocol would prefer to encode each record independently in the protocol. This requires the nmred/kafka-php library, version >= 1.3.0. Adds a new formatter which serializes to the apache avro format. This is a compact binary format which uses pre- defined schemas. This initial implementation is very simple and takes the plain schemas as a constructor argument. Adds a new option to MonologSpi to wrap handlers in a BufferHandler. This doesn't flush until the request shuts down and prevents any network requests in the logger from adding latency to web requests. Related mediawiki/vendor update: Ibfe4bd2036ae8e998e2973f07bd9a6f057691578 The necessary config is something like: array( 'loggers' => array( 'CirrusSearchRequests' => array( 'handlers' => array( 'kafka' ), ), ), 'handlers' => array( 'kafka' => array( 'factory' => '\\MediaWiki\\Logger\\Monolog\\KafkaHandler::factory', 'args' => array( 'localhost:9092' ), 'formatter' => 'avro', 'buffer' => true, ), ), 'formatters' => array( 'avro' => array( 'class' => '\\MediaWiki\\Logger\\Monolog\\AvroFormatter', 'args' => array( array( 'CirrusSearchRequests' => array( 'type' => 'record', 'name' => 'CirrusSearchRequests' 'fields' => array( ... ) ), ), ), ), ), ) Bug: T106256 Change-Id: I6ee744b3e5306af0bed70811b558a543eed22840
2015-08-04 18:02:47 +00:00
"nmred/kafka-php": "Send debug log events to kafka",
"pear/mail": "Mail sending support",
"pear/mail_mime": "Mail sending support",
Produce monolog messages through kafka+avro This allows a logging channel to be configured to write directly to kafka. Logs can be serialized either to json blobs or the more compact apache avro format. The Kafka handler for monolog needs a list of one of more kafka servers to query cluster metadata from. This should be able to use any monolog formatter, although some like JsonFormatter require you to disable formatBatch as Kafka protocol would prefer to encode each record independently in the protocol. This requires the nmred/kafka-php library, version >= 1.3.0. Adds a new formatter which serializes to the apache avro format. This is a compact binary format which uses pre- defined schemas. This initial implementation is very simple and takes the plain schemas as a constructor argument. Adds a new option to MonologSpi to wrap handlers in a BufferHandler. This doesn't flush until the request shuts down and prevents any network requests in the logger from adding latency to web requests. Related mediawiki/vendor update: Ibfe4bd2036ae8e998e2973f07bd9a6f057691578 The necessary config is something like: array( 'loggers' => array( 'CirrusSearchRequests' => array( 'handlers' => array( 'kafka' ), ), ), 'handlers' => array( 'kafka' => array( 'factory' => '\\MediaWiki\\Logger\\Monolog\\KafkaHandler::factory', 'args' => array( 'localhost:9092' ), 'formatter' => 'avro', 'buffer' => true, ), ), 'formatters' => array( 'avro' => array( 'class' => '\\MediaWiki\\Logger\\Monolog\\AvroFormatter', 'args' => array( array( 'CirrusSearchRequests' => array( 'type' => 'record', 'name' => 'CirrusSearchRequests' 'fields' => array( ... ) ), ), ), ), ), ) Bug: T106256 Change-Id: I6ee744b3e5306af0bed70811b558a543eed22840
2015-08-04 18:02:47 +00:00
"pear/mail_mime-decode": "Mail sending support",
"wikimedia/avro": "Binary serialization format used with kafka"
},
"autoload": {
"psr-0": {
"ComposerHookHandler": "includes/composer"
},
"files": [
"includes/compat/Timestamp.php"
]
},
"autoload-dev": {
"files": [
"vendor/hamcrest/hamcrest-php/hamcrest/Hamcrest.php",
"vendor/wmde/hamcrest-html-matchers/src/functions.php"
]
},
"scripts": {
"lint": "parallel-lint --exclude vendor",
"phpcs": "phpcs -p -s",
"fix": "phpcbf",
"pre-install-cmd": "ComposerHookHandler::onPreInstall",
"pre-update-cmd": "ComposerHookHandler::onPreUpdate",
"test": [
"composer lint",
"composer phpcs"
]
},
"config": {
"optimize-autoloader": true,
"prepend-autoloader": false
},
"extra": {
"merge-plugin": {
"include": [
"composer.local.json"
],
"merge-dev": false
}
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
2014-05-11 10:00:35 +00:00
}
}