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

Assigned To

None

Authored By

	Reedy
	Nov 10 2017, 2:18 PM

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?

Related Objects
Search...

Status	Assigned	Task
Resolved	Reedy	T180272 Release MediaWiki 1.27.4/1.28.3/1.29.2
Resolved	• demon	T169127 Release MediaWiki 1.30
Resolved	Reedy	T168823 Tracking bug for 1.27.4/1.28.3/1.29.2 security releases
Resolved	Reedy	T180231 MW 1.27 and 1.28 require-dev versions of phpunit with known security issues
Declined	None	T180233 Set `no-dev` as the default config in composer.json
Declined	None	T180235 Run composer with `--dev` flag

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 created subtask T180235: Run composer with `--dev` flag.Nov 10 2017, 2:20 PM

Reedy removed projects: MW-1.28-release, MW-1.27-release.

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.

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)

Created an explicit request at https://github.com/composer/composer/issues/6797

hashar mentioned this in T180235: Run composer with `--dev` flag.Nov 10 2017, 8:11 PM

Reedy changed the visibility from "Custom Policy" to "Public (No Login Required)".Nov 15 2017, 12:06 AM

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

Kghbln awarded a token.Nov 15 2017, 10:04 AM

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....

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.