| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the initial step towards implementing the Structured logging RFC
[0].
The Psr\Log library is declared as a requirement in the composer.json
file and Monolog is suggested as a package that can enhance MediaWiki.
To use this in a local checkout:
* Install composer [1]
* `composer update`
* `composer require monolog/monolog 1.9.*`
* `composer dump-autoload --optimize`
* `git update-index --assume-unchanged composer.json`
Additional work will be needed to provide both the Psr\Log and Monolog
libraries available for deployment to the Wikimedia Foundation servers.
The Psr\Log library will also need to be packaged in the release
tarballs.
[0]: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging
[1]: https://getcomposer.org/doc/00-intro.md#installation-nix
See also: I1431b24 (Monolithic implementation)
Change-Id: Ie667944416187cfd2ae6016c9e2fa28f4204bcd7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change it is possible for users to create a composer.json
file in which they list the extensions they want to have installed
and then install them via Composer. They can copy composer-example.json
to get started.
Before this change there was an actual composer.json file tracked by
git, so people would get a change tracked by git if they modified it.
Surprisingly this is all that is needed to get extension installation
to work, for the extensions that already support it. Kudos to hashar
and others that already did the other required work.
With this change core no longer pretends to be a component that is
installable via composer. This never worked, and core will need to
be modified in several ways before this can work. In other words,
no working functionality is lost, and quite a lot is gained.
Example usage:
* Copy composer-example.json to composer.json.
* Run "composer require diff/diff 0.9"
* Hit Special:Version and be happy
Change-Id: Ib125bea00cd29a800c22f260e87dfe3327a0b618
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So it turns out you're not supposed to specify the repository in
composer.json, as that's only for dependencies. Otherwise it will loop
infinitely.
The repository tag isn't for the current application, it's for
dependencies of the application. I've tried doing "composer install"
with MediaWiki master and it loops infinitely because it goes to the
repository, sees that it has a composer.json, reads it, sees that it has
a repository, etc.
This patch thus Remove the 'repositories' statement pointing to
Wikimedia gerrit installation which as added with 0ee7f355
Change-Id: I9a77d28f33a0b966f42c8c2e952b922809acc20d
|
| |
|
|
|
|
|
|
|
| |
* repository information so version information can be inferred from
tags rather than set statically.
* phpunit as a dev requirement
* APC as a suggested package.
Change-Id: I3f5b07c716e7aa426484bd313af09801c6e3fde2
|
| |
|
|
| |
Change-Id: I1661298e404ba25eae3d546baa77ed98f227b82f
|
| |
|
|
| |
Change-Id: I0668f7dbacb7fc9c02d774bf58ab4787637617af
|
|
|
Change-Id: I9fc76e3fdecf428c5296ddad812006cb3cca3d23
|
