Page MenuHomePhabricator

Set `no-dev` as the default config in composer.json
Closed, DeclinedPublic

Description

EDIT: This is blocked on Upstream per the comment at https://github.com/composer/composer/issues/3008#issuecomment-210541879

To ease the burden of end users running composer with --no-dev (and remembering to RTFM T180232: Document to run composer with `--no-dev`) it would be a lot easier if we could set no-dev to true in the composer config

This may require some changes to the CI config to make sure we're running composer (update|install) with --dev instead, but this should be a small maintenance burden

Should we try and roll this out to extensions too when doing other maintenance updates/bumps?

Event Timeline

Reedy created this task.Nov 10 2017, 2:18 PM
Reedy created this object with visibility "Custom Policy".
Reedy updated the task description. (Show Details)
Reedy changed the task status from Open to Stalled.Nov 10 2017, 2:24 PM
Reedy added a project: Upstream.
Reedy updated the task description. (Show Details)
Reedy changed the status of subtask T180235: Run composer with `--dev` flag from Open to Stalled.
Reedy added a subscriber: Hutchy68.Nov 10 2017, 2:35 PM

This may end up being a declined by upstream not wanting to do it...

Reedy updated the task description. (Show Details)Nov 10 2017, 2:36 PM
Reedy updated the task description. (Show Details)
Reedy changed the visibility from "Custom Policy" to "Public (No Login Required)".Nov 15 2017, 12:06 AM
Kghbln added a subscriber: Kghbln.Nov 15 2017, 10:04 AM

From past experience with this upsteam project I am afraid that they will be defining reality here.

Basically, they said something about we (them included, maybe?) should be educating people better...

People just want to make mediawiki work... composer update is easier to remember than composer update --no-dev etc....

bd808 added a subscriber: bd808.EditedNov 15 2017, 11:23 PM

It used to work correctly for what its worth:
https://github.com/composer/composer/blob/master/CHANGELOG.md#100-alpha8---2014-01-06

* Break: The install command now has --dev enabled by default. --no-dev can be used to install without dev requirements

https://github.com/composer/composer/blob/master/CHANGELOG.md#100-alpha7---2013-05-04

* Break: For forward compatibility, you should change your deployment scripts to run composer install --no-dev. The install command will install dev dependencies by default starting in the next release
* Break: The update command now has --dev enabled by default. --no-dev can be used to update without dev requirements, but it will create an incomplete lock file and is discouraged

The behavior change was apparently made first to fix a composer.lock dirty file problem and then for symmetry.

A potential fix would be to make our own CLI install manager system. This could start as a thin wrapper around Composer and grow as needed to encompass things like extension and skin management. This CLI manager could be self-hosted in mediawiki/core.git and self-bootstrapping as well. The hard part of this is finding a set of interested developers to design, implement, and maintain yet another component that is only tangentially related to the core system.

It would be awesome to find an all encompassing soltution to problem of software distribution and configuration ready made for general use. This is probably an impossible dream however without other serious philosophical and platform lock-in. You either have to live with the philosophy of the tool maintainers or you have to forge ahead on your own. The Wikimedia Foundation has invested in tools that assist in deployment and configuration for their wiki farm (scap and multiverison), but these solutions are very specifically tailored to the needs of the Wikimedia production cluster. More general purpose solutions may be possible, but they certainly will not be trivial to implement and maintain.

Reedy closed this task as Declined.Nov 29 2017, 1:12 PM

https://github.com/composer/composer/issues/6797

It's a no from them.

Might be worth forking @bd808's "thin wrapper" idea into a new task at least