RfC: Extension management with Composer
Closed, DeclinedPublic

Description

Related Objects

Qgil created this task.Sep 22 2014, 8:48 AM
Qgil updated the task description. (Show Details)
Qgil raised the priority of this task from to High.
Qgil added a project: Architecture.
Qgil changed Security from none to None.
Qgil moved this task from Inbox to Ready to Go on the Architecture board.
Qgil added a subscriber: Qgil.
Qgil added a comment.Sep 22 2014, 8:54 AM

This RfC will be discussed in the next rfC meeting on Wednesday 24 at 21:00 UTC: https://lists.wikimedia.org/pipermail/wikitech-l/2014-September/078698.html

Qgil added a comment.Sep 25 2014, 12:13 PM

Meeting logs.

  • https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_with_Composer (TimStarling, 21:02:11)
  • if the composer dev team want to support mediawiki extensions, then we should probably help them with that (TimStarling, 21:27:00)
  • legoktm: So, I don't really see composer as something that as necessary to improve "extension management" (TimStarling, 21:27:16)
  • Daniel thinks composer would be useful in managing dependencies between extensions etc. (TimStarling, 21:28:05)
  • composer manages dependencies, but currenly has no support for optional extensions/plugins/modules. when used naively, extensions would pull in core as a library. (DanielK_WMDE_, 21:28:37)
  • probably best to do the "extension registration" RFC first and this RFC second (TimStarling, 21:29:02)
  • ACTION: mglaser will propose requirements on the RfC and ask you all for comments (TimStarling, 21:30:40)
  • ACTION: mglaser will try to get in touch with the guy in Berlin via lydia (TimStarling, 21:30:50)
Qgil moved this task from Ready to Go to External on the Architecture board.Sep 25 2014, 12:14 PM
Qgil lowered the priority of this task from High to Normal.
Qgil edited projects, added TechCom-RFC; removed Architecture.Oct 22 2014, 8:45 PM
Kghbln added a subscriber: Kghbln.Nov 20 2014, 9:04 AM
daniel moved this task from Inbox to Backlog on the TechCom-RFC board.Feb 27 2015, 3:12 PM
daniel assigned this task to Mglaser.Feb 27 2015, 3:31 PM
daniel added a subscriber: daniel.

We discussed this in the latest #mwstake meeting. Some action items and notes:

  • Cindy: there's a showstopper for composer for them. It is not possible to turn extension on and off separately without turning off the dependencies. Reluctant to put up the effort of using it als long as the usage is still unclear.
  • Karsten agrees. It's hard to use it in environments that are not homogenous.
  • Lot of focus on single wiki use case.
  • Should we reach out to the composer people?
  • ACTION; Markus. find contact of composer people and send it to Cindy and Karsten
  • ACTION: Cindy and Karsten get in touch with composer people
  • There's a new way of extension registration. Does composer still apply?
  • Markus: let's work towards separation of concerns. And work
MarkAHershberger closed this task as Declined.Jun 6 2015, 8:34 PM

https://github.com/composer/composer/issues/4109 for a response from the Composer people on something that is essential for WikiFarms. WONTFIX.

This seems a weird decision to me. Composer *without* autoload entries works very well with extension registrations wfLoadExtensions.

I very much dislike how this RfC resolution is used to forbid people to use composer with extensions, see https://gerrit.wikimedia.org/r/#/c/190027/ for example. This resolution has not even been communicated on Wikitech-l.

@Nikerabbit: the decision is to not use composer to register components. That is, composer's autoload feature should not be used to execute an extension's entry. Composer can and should be used to pull in any dependencies an extension may have, and it may also be used to install the code of an extension, and to auto-load an extension's classes. It shall not be used to activate the extension - for that, the wfLoadExtensions should be used.

@Nikerabbit: the decision is to not use composer to register components. That is, composer's autoload feature should not be used to execute an extension's entry. Composer can and should be used to pull in any dependencies an extension may have, and it may also be used to install the code of an extension, and to auto-load an extension's classes. It shall not be used to activate the extension - for that, the wfLoadExtensions should be used.

@daniel based on this clear statement, what can/should we do to a) publicize this decision and b) help convert extensions that are currently in violation?
(not sure if that is a patronizing we, dictorial we or a more friendly inclusive we)

Perhaps document this on https://www.mediawiki.org/wiki/Manual:Composer.json_best_practices ? And make a task listing the extensions that need fixing then propose patches for them?

Qgil removed a subscriber: Qgil.Aug 8 2015, 10:07 AM
Osnard added a subscriber: Osnard.Nov 27 2017, 11:13 AM