wiki.techinc.nl/composer.json

90 lines
2.5 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.2.0",
"cssjanus/cssjanus": "1.1.2",
"ext-iconv": "*",
"liuggio/statsd-php-client": "1.0.18",
"mediawiki/at-ease": "1.1.0",
"oojs/oojs-ui": "0.14.1",
"oyejorge/less.php": "1.7.0.9",
"php": ">=5.3.3",
"psr/log": "1.0.0",
"wikimedia/assert": "0.2.2",
"wikimedia/base-convert": "1.0.1",
"wikimedia/cdb": "1.3.0",
"wikimedia/cldr-plural-rule-parser": "1.0.0",
"wikimedia/composer-merge-plugin": "1.3.0",
"wikimedia/ip-set": "1.0.1",
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/running-stat": "1.1.0",
"wikimedia/utfnormal": "1.0.3",
"wikimedia/wrappedstring": "2.0.0",
"zordius/lightncandy": "0.21"
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": {
"jakub-onderka/php-parallel-lint": "0.9",
Implement extension registration from an extension.json file Introduces wfLoadExtension()/wfLoadSkin() which should be used in LocalSettings.php rather than require-ing a PHP entry point. Extensions and skins would add "extension.json" or "skin.json" files in their root, which contains all the information typically present in PHP entry point files (classes to autoload, special pages, API modules, etc.) A full schema can be found at docs/extension.schema.json, and a script to validate these to the schema is provided. An additional script is provided to convert typical PHP entry point files into their JSON equivalents. The basic flow of loading an extension goes like: * Get the ExtensionRegistry singleton instance * ExtensionRegistry takes a filename, reads the file or tries to get the parsed JSON from APC if possible. * The JSON is run through a Processor instance, which registers things with the appropriate global settings. * The output of the processor is cached in APC if possible. * The extension/skin is marked as loaded in the ExtensionRegistry and a callback function is executed if one was specified. For ideal performance, a batch loading method is also provided: * The absolute path name to the JSON file is queued in the ExtensionRegistry instance. * When loadFromQueue() is called, it constructs a hash unique to the members of the current queue, and sees if the queue has been cached in APC. If not, it processes each file individually, and combines the result of each Processor into one giant array, which is cached in APC. * The giant array then sets various global settings, defines constants, and calls callbacks. To invalidate the cached processed info, by default the mtime of each JSON file is checked. However that can be slow if you have a large number of extensions, so you can set $wgExtensionInfoMTime to the mtime of one file, and `touch` it whenever you update your extensions. Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
"justinrainbow/json-schema": "~1.3",
"mediawiki/mediawiki-codesniffer": "0.4.0",
"monolog/monolog": "~1.17.2",
"nmred/kafka-php": "0.1.4",
"phpunit/phpunit": "3.7.37",
"wikimedia/avro": "1.7.7"
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-fileinfo": "Improved mime magic detection",
"ext-intl": "ICU integration",
"ext-mbstring": "Multibyte string support",
"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"
}
},
"scripts": {
"lint": "parallel-lint --exclude vendor",
"phpcs": "phpcs -p $PHPCS_ARGS",
"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
}
}