add --prefer-lowest and --prefer-stable to update command #3450

nicolas-grekas · 2014-11-21T13:04:10Z

Run composer update --prefer-lowest-stable and get all the deps installed to their lowest (pretended) supported version

Fixes #3440
Fixes #1902

stof · 2014-11-21T13:12:54Z

@naderman there is a protected method selectNewestPackages in the DefaultPolicy class, but it looks unused. What is its goal ?

naderman · 2014-11-21T14:25:10Z

@stof used to be a helper method for selectPreferedPackages, I'll delete it as it's no longer used.

naderman · 2014-11-21T14:27:16Z

5333017

nicolas-grekas · 2014-11-21T15:28:08Z

Please tell me if I should do anything before merge

stof · 2014-11-21T15:28:59Z

hmm, adding an integration test covering this case to ensure it works ?

naderman · 2014-11-21T15:29:40Z

Only thing I wonder is if we should have a regular prefer lowest without prefer stable? /cc @Seldaek @stof

stof · 2014-11-21T15:31:06Z

src/Composer/Installer.php

@@ -697,10 +698,14 @@ private function createPolicy()
        // old lock file without prefer stable will return null
        // so in this case we use the composer.json info
        if (null === $preferStable) {
-            $preferStable = $this->package->getPreferStable();
+            if (getenv('COMPOSER_PREFER_LOWEST_STABLE')) {
+                $preferStable = $preferLowest = true;


are you sure about $preferStable being true ? this would prefer a 2.4.0 over a 2.4.0-beta release, while 2.4.0 is lowest.
I think it should rather force $preferStable to false, so that only the version ordering is used to find the selected version

Yeah that's what I meant, currently it's called LOWEST_STABLE so that makes sense, but maybe we should support both LOWEST and LOWEST_STABLE?

In fact, I tried without prefer-stable, and I went back in -rc1 or -alpha state, which is certainly not what I'll ever want to test. So, if the only use case of this is testing the lowest version you pretend to support, I'm not sure that anyone will go up to supporting alpha nor even beta versions.

nicolas-grekas · 2014-11-21T18:15:22Z

I just added a small unit test. For the integration test, there is none for other ENV vars...

naderman · 2014-11-21T18:16:58Z

well other env vars have a config equivalent, this does not?

naderman · 2014-11-21T18:18:41Z

This should probably also somehow use the new getComposerEnv() to avoid accidentally influencing test behavior with environment variables set in the process. https://github.com/composer/composer/blob/master/src/Composer/Config.php#L306

nicolas-grekas · 2014-11-21T19:03:28Z

Rebased to use config->getComposerEnv().
There is no corresponding config option because I followed comments on #3440,
please tell me if I should update.

naderman · 2014-11-21T19:35:57Z

Yes I didn't mean to ask for one, just meant that's why there probably aren't env tests for the others?

nicolas-grekas · 2014-11-21T20:55:43Z

I added a line in the travis-ci matrix so that composer itself is tested with its lowest deps.
That made me fix the composer.json.

nicolas-grekas · 2014-11-22T23:57:03Z

In fact, while trying to correctly test composer with the new flag, I've been hit by the same problem as in #3448 So, I replaced the env var by an option on the update command.
To make tests pass with the new line in the .travis file, I also had to remove phpunit from require-dev, because in fact, your tests relies on an implicit version of phpunit's deps.
Tests are green again now.

naderman · 2014-11-26T18:26:17Z

Err I understood all of that except why you had to remove phpunit from require-dev?

nicolas-grekas · 2014-11-26T19:31:57Z

It's because tests do not pass: phpunit itself is broken when setuped with --prefer-lowest-stable

naderman · 2014-11-26T19:46:56Z

Hm I see, but shouldn't we find another solution to that then than remove the dependency on phpunit which we kind of need to test locally?

nicolas-grekas · 2014-12-02T08:46:17Z

So, spending one more hour on this, I still don't see any use case for specifying "prefer-lowest" but not "prefer-stable" together. In fact, and because I fail to imagine a use case, I fear people will start using "prefer-lowest XOR prefer-stable", and you'll get issues and increase support on your side.

Still, I added a commit that splits --prefer-lowest and --prefer-stable so everybody is happy :)

Really, after spending time on it, I see a flaw in your reasoning @naderman that may explain our respective pov: when someone sets @dev to a requirement, it never meant that the very first commit in the git history of that package is supported - but the exact opposite: only the very latest commit is supported.
This is very different from a "~2.3" which states explicitly that "2.3.0 and more" is supported.

Did you checkout my branch and run it against e.g. composer and/or symfony? If not, then you really should. That's the experimental argument that made me understand and have my current way of thinking.

I'd be happy to remove this last commit if you come to the same conclusion as mine. Or you can merge as is now if you prefer.

dbu · 2014-12-02T09:11:30Z

if my only dependency is "@dev" or something equally funny, then i can
install with any version. if i use some library with "@dev", but my
project asks for "0.1.*@dev" i will end up with some old version (assume
there was never a stable 0.1 release for example.

Seldaek · 2014-12-13T13:23:55Z

@nicolas-grekas could you give an example of a package where it didn't do the right thing for you? Because even with @dev it wouldn't install the oldest commit since it has no knowledge of all commits, if a library has: 1.0, 1.1, 1.2.x-dev (master) as versions, the lowest, even with @dev, is 1.0.

nicolas-grekas · 2014-12-13T14:52:51Z

Of course: any Symfony component with dependencies.
Here is for DependencyInjection when adding --prefer-stable after a first run with only --prefer-lowest:

> composer update --prefer-lowest --prefer-stable
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Updating symfony/expression-language (v2.4.0-BETA1 => v2.4.0)
    Checking out 54ee1629680bf4313412cef284c6b19fd64c7a29

Seldaek · 2014-12-13T14:59:49Z

Yes that makes sense, you use the first beta available as that is what a ~2.4 requirement specifies (any 2.4..). It may not be what everyone wants but strictly speaking that's what prefer-lowest should do IMO. If you use it you get what you ask for. But it probably makes sense to combine with --prefer-stable to most people :)

nicolas-grekas · 2014-12-13T15:02:16Z

Cool, then we can merge as is?

Seldaek · 2014-12-13T15:05:01Z

src/Composer/Installer.php

@@ -700,10 +703,11 @@ private function createPolicy()
        // old lock file without prefer stable will return null


Would you mind adding prefer-lowest support for the lock file? I understand it's probably not a common use case or none at all but for completeness and to avoid bad surprises it should be persisted to the lock. See a few lines above..

Hum, not sure to understand... Can you drive me a bit more please?

Sure, basically the same as https://github.com/composer/composer/pull/3101/files + nicolas-grekas@4bd748b which fixed some mistakes :)

Except preferLowest isn't on the root $package so you'll have to pass it in to the locker directly I guess.

Seldaek · 2014-12-13T15:05:24Z

Yes except for the lock support sorry I missed that last time :)

dbu · 2014-12-13T16:40:41Z

Yes that makes sense, you use the first beta available as that is what a ~2.4 requirement specifies (any 2.4..). It may not be what everyone wants but strictly speaking that's what prefer-lowest should do IMO. If you use it you get what you ask for. But it probably makes sense to combine with --prefer-stable to most people :)

If my bundle claims to work with 2.4.0-alpha1 or later, by using ~2.4 then it should be tested with that. so i notice that i should have restricted that to whatever version i am actually compatible with.

Seldaek · 2014-12-13T16:46:11Z

@dbu I agree on principle but in effect nobody is likely to use your bundle with 2.4.0-alpha1 once a 2.4.0 stable is out, but ~2.4 will allow the alpha still, unless you do ~2.4-stable. Under normal conditions composer will take the stable if it's there anyway so I would say for "compat testing" --prefer-stable --prefer-lowest sounds reasonable (you'll catch problems but not waste time debugging issues occuring only with alpha/beta versions of your deps).

dbu · 2014-12-13T17:29:57Z

okay. did not want to argue against the combination of --prefer-stable and --prefer-lowest, only that --prefer-lowest alone should install an alpha or beta.

Seldaek · 2014-12-13T17:31:01Z

Ah ok yes for sure :)

nicolas-grekas · 2014-12-13T22:57:11Z

prefer-lowest is now persisted in composer.lock

alcohol · 2014-12-13T23:17:29Z

Can you be sure to update doc/03-cli.md and doc/04-schema.md?

nicolas-grekas · 2014-12-14T09:15:23Z

CLI doc updated (but there is no schema change for composer.json)

Seldaek · 2014-12-14T13:02:04Z

Great, looks very complete now, thanks @nicolas-grekas!

add --prefer-lowest and --prefer-stable to update command

…s-grekas) This PR was squashed before being merged into the 2.3 branch (closes #12542). Discussion ---------- Test components using their lowest possible deps | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Once composer/composer#3450 is merged, we'll see if our deps are correct, and ensure that is kept over time by testing each component with its lowest possible deps. Commits ------- 25fef27 Test components using their lowest possible deps

stof reviewed Nov 21, 2014
View reviewed changes

nicolas-grekas force-pushed the prefer-lowest-stable branch from c632c7f to b6b4949 Compare November 21, 2014 18:13

nicolas-grekas mentioned this pull request Nov 21, 2014

Test components using their lowest possible deps symfony/symfony#12542

Closed

nicolas-grekas force-pushed the prefer-lowest-stable branch from b6b4949 to be8282c Compare November 21, 2014 19:00

nicolas-grekas force-pushed the prefer-lowest-stable branch from 43d4b3a to 0fa6e79 Compare November 21, 2014 20:53

nicolas-grekas force-pushed the prefer-lowest-stable branch 8 times, most recently from fb0b747 to 0dafd11 Compare November 22, 2014 20:15

nicolas-grekas changed the title ~~add COMPOSER_PREFER_LOWEST_STABLE~~ add --prefer-lowest-stable to update command Nov 22, 2014

docteurklein mentioned this pull request Dec 2, 2014

Refactor/bump php symfony version phpspec/phpspec#571

Closed

nicolas-grekas added 2 commits December 13, 2014 11:51

add --prefer-lowest-stable to update command

4a0feb0

split update --prefer-lowest and --prefer-stable

98b254a

nicolas-grekas force-pushed the prefer-lowest-stable branch from a896606 to 98b254a Compare December 13, 2014 10:51

nicolas-grekas changed the title ~~add --prefer-lowest-stable to update command~~ add --prefer-lowest and --prefer-stable to update command Dec 13, 2014

Seldaek reviewed Dec 13, 2014
View reviewed changes

nicolas-grekas force-pushed the prefer-lowest-stable branch from f4fe6a7 to 7c2cade Compare December 14, 2014 09:14

nicolas-grekas force-pushed the prefer-lowest-stable branch from 7c2cade to e9d2335 Compare December 14, 2014 09:28

Persist prefer-lowest in composer.lock

e821ac2

nicolas-grekas force-pushed the prefer-lowest-stable branch from e9d2335 to e821ac2 Compare December 14, 2014 09:29

Seldaek added a commit that referenced this pull request Dec 14, 2014

Merge pull request #3450 from nicolas-grekas/prefer-lowest-stable

901fd83

add --prefer-lowest and --prefer-stable to update command

Seldaek merged commit 901fd83 into composer:master Dec 14, 2014

nicolas-grekas deleted the prefer-lowest-stable branch December 14, 2014 14:08

nicolas-grekas mentioned this pull request Dec 15, 2014

[2.5] Fixed the proxy-manager version constraint symfony/symfony#12832

Closed

		@@ -700,10 +703,11 @@ private function createPolicy()
		// old lock file without prefer stable will return null

add --prefer-lowest and --prefer-stable to update command #3450

add --prefer-lowest and --prefer-stable to update command #3450

Conversation

nicolas-grekas commented Nov 21, 2014

stof commented Nov 21, 2014

naderman commented Nov 21, 2014

naderman commented Nov 21, 2014

nicolas-grekas commented Nov 21, 2014

stof commented Nov 21, 2014

naderman commented Nov 21, 2014

stof Nov 21, 2014

Choose a reason for hiding this comment

naderman Nov 21, 2014

Choose a reason for hiding this comment

nicolas-grekas Nov 21, 2014

Choose a reason for hiding this comment

nicolas-grekas commented Nov 21, 2014

naderman commented Nov 21, 2014

naderman commented Nov 21, 2014

nicolas-grekas commented Nov 21, 2014

naderman commented Nov 21, 2014

nicolas-grekas commented Nov 21, 2014

nicolas-grekas commented Nov 22, 2014

naderman commented Nov 26, 2014

nicolas-grekas commented Nov 26, 2014

naderman commented Nov 26, 2014

nicolas-grekas commented Dec 2, 2014

dbu commented Dec 2, 2014

Seldaek commented Dec 13, 2014

nicolas-grekas commented Dec 13, 2014

Seldaek commented Dec 13, 2014

nicolas-grekas commented Dec 13, 2014

Seldaek Dec 13, 2014

Choose a reason for hiding this comment

nicolas-grekas Dec 13, 2014

Choose a reason for hiding this comment

Seldaek Dec 13, 2014

Choose a reason for hiding this comment

Seldaek Dec 13, 2014

Choose a reason for hiding this comment

Seldaek commented Dec 13, 2014

dbu commented Dec 13, 2014

Seldaek commented Dec 13, 2014

dbu commented Dec 13, 2014

Seldaek commented Dec 13, 2014

nicolas-grekas commented Dec 13, 2014

alcohol commented Dec 13, 2014

nicolas-grekas commented Dec 14, 2014

Seldaek commented Dec 14, 2014