I've opened a task on Phabricator[1] to attempt to merge the information in extension.json with Composer's already-used-by-several-extensions-and-skins composer.json.
Kunal has rightly pointed out that composer doesn't fit some use-cases for MediaWiki. I see that as an opportunity to be good citizens in the larger developer community by working to integrate MediaWiki into the growing ecosystem available on packagist.org.
For example, if composer had been available, we might not have had to develop our own HTTP client.
If composer had been available, Brion could have released the work under includes/normal as its own package. As he says in the README there:
This directory contains some Unicode normalization routines. These routines are meant to be reusable in other projects, so I'm not tying them to the MediaWiki utility functions.
(Of course, there was PEAR, but that is ugly and centralized in a way that composer is not.)
Using Composer for extensions also reduces the learning curve for developers who want to adapt their work (which may already be available via Composer) to be used in MediaWiki. It helps us increase the size of the available developer community without too much effort.
Footnotes: [1] https://phabricator.wikimedia.org/T89456
On Mon, Feb 16, 2015 at 10:34 AM, Mark A. Hershberger mah@nichework.com wrote:
I've opened a task on Phabricator[1] to attempt to merge the information in extension.json with Composer's already-used-by-several-extensions-and-skins composer.json.
Kunal has rightly pointed out that composer doesn't fit some use-cases for MediaWiki. I see that as an opportunity to be good citizens in the larger developer community by working to integrate MediaWiki into the growing ecosystem available on packagist.org.
For example, if composer had been available, we might not have had to develop our own HTTP client.
If composer had been available, Brion could have released the work under includes/normal as its own package. As he says in the README there:
This directory contains some Unicode normalization routines. These routines are meant to be reusable in other projects, so I'm not tying them to the MediaWiki utility functions.(Of course, there was PEAR, but that is ugly and centralized in a way that composer is not.)
Using Composer for extensions also reduces the learning curve for developers who want to adapt their work (which may already be available via Composer) to be used in MediaWiki. It helps us increase the size of the available developer community without too much effort.
Footnotes: [1] https://phabricator.wikimedia.org/T89456
For those new to this discussion, review of the talk page for the Improving extension management RFC [0] and the Extension management with Composer RFC [1] and it's talk page [2] would be advised.
I'd love to see this discussion become more unified rather than more fragmented as I believe that an improved versioning, compatibility and loading system for extensions is an important topic for the future of MediaWiki.
[0]: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Improving_extension... [1]: https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_wit... [2]: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Extension_managemen...
Bryan
On 2015-02-16 9:34 AM, Mark A. Hershberger wrote:
I've opened a task on Phabricator[1] to attempt to merge the information in extension.json with Composer's already-used-by-several-extensions-and-skins composer.json.
Kunal has rightly pointed out that composer doesn't fit some use-cases for MediaWiki. I see that as an opportunity to be good citizens in the larger developer community by working to integrate MediaWiki into the growing ecosystem available on packagist.org.
For example, if composer had been available, we might not have had to develop our own HTTP client.
If composer had been available, Brion could have released the work under includes/normal as its own package. As he says in the README there:
This directory contains some Unicode normalization routines. These routines are meant to be reusable in other projects, so I'm not tying them to the MediaWiki utility functions.
It looks like two things are being conflated here. - Use of composer to use 3rd party libraries and publish the generic code we create as libraries other people can use. - Use of composer to distribute and install MediaWiki Extensions isolated to the MediaWiki ecosystem.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 02/16/2015 09:34 AM, Mark A. Hershberger wrote:
I've opened a task on Phabricator[1] to attempt to merge the information in extension.json with Composer's already-used-by-several-extensions-and-skins composer.json.
Can we please centralize this discussion? We're discussing this on-wiki, and now it's spread to Phabricator and wikitech-l.
Kunal has rightly pointed out that composer doesn't fit some use-cases for MediaWiki. I see that as an opportunity to be good citizens in the larger developer community by working to integrate MediaWiki into the growing ecosystem available on packagist.org.
For example, if composer had been available, we might not have had to develop our own HTTP client.
I don't buy this argument. If there had been code available for us to use and there was an advantage to using it instead of writing our own, we probably would have just copied it into core like we have done with other PHP code in includes/libs/. But this has already been discussed before[1].
If composer had been available, Brion could have released the work under includes/normal as its own package. As he says in the README there:
This directory contains some Unicode normalization routines. These routines are meant to be reusable in other projects, so I'm not tying them to the MediaWiki utility functions.
There's nothing stopping us from doing that now. I've moved the code to includes/libs/normal, so it shouldn't be too difficult.[2]
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components [2] https://phabricator.wikimedia.org/T88485
-- Legoktm
Legoktm legoktm.wikipedia@gmail.com writes:
Can we please centralize this discussion? We're discussing this on-wiki, and now it's spread to Phabricator and wikitech-l.
I apologize for the diffusion.
I'm trying to get attention on this issue, but obviously I've overstepped. I'm fine with continuing on-wiki and in the RFC discussion that is planned.
I'll restrict my response here.
For example, if composer had been available, we might not have had to develop our own HTTP client.
I don't buy this argument. If there had been code available for us to use and there was an advantage to using it instead of writing our own, we probably would have just copied it into core like we have done with other PHP code in includes/libs/.
Since I did some work on the HTTP client, I like to think I have some insight. We wouldn't have copied the other code into includes/libs since that didn't exist at the time. The PEAR module existed, but we had already begun developing our own very lightweight client at that time that I started working on it.
At the time that I started working on it, the PEAR module looked too heavyweight. Maybe it is re-evaluate the code to use.
It is good to see that we've begun making the code we produce more sharable, so thanks for your help there, Kunal.
Mark.
wikitech-l@lists.wikimedia.org