Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 3 commits into from Dec 14, 2014

Conversation

@nicolas-grekas
Copy link
Contributor

@nicolas-grekas nicolas-grekas commented Nov 21, 2014

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

Fixes #3440
Fixes #1902

@stof
Copy link
Contributor

@stof stof commented Nov 21, 2014

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

@naderman
Copy link
Member

@naderman naderman commented Nov 21, 2014

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

@naderman
Copy link
Member

@naderman naderman commented Nov 21, 2014

@nicolas-grekas
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Nov 21, 2014

Please tell me if I should do anything before merge

@stof
Copy link
Contributor

@stof stof commented Nov 21, 2014

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

@naderman
Copy link
Member

@naderman naderman commented Nov 21, 2014

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

@@ -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;

This comment has been minimized.

@stof

stof Nov 21, 2014
Contributor

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

This comment has been minimized.

@naderman

naderman Nov 21, 2014
Member

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?

This comment has been minimized.

@nicolas-grekas

nicolas-grekas Nov 21, 2014
Author Contributor

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 nicolas-grekas force-pushed the nicolas-grekas:prefer-lowest-stable branch from c632c7f to b6b4949 Nov 21, 2014
@nicolas-grekas
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Nov 21, 2014

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

@naderman
Copy link
Member

@naderman naderman commented Nov 21, 2014

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

@naderman
Copy link
Member

@naderman naderman commented Nov 21, 2014

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
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Nov 21, 2014

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
Copy link
Member

@naderman naderman commented Nov 21, 2014

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 nicolas-grekas force-pushed the nicolas-grekas:prefer-lowest-stable branch from 43d4b3a to 0fa6e79 Nov 21, 2014
@nicolas-grekas
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Nov 21, 2014

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 nicolas-grekas force-pushed the nicolas-grekas:prefer-lowest-stable branch 8 times, most recently from fb0b747 to 0dafd11 Nov 22, 2014
@nicolas-grekas nicolas-grekas changed the title add COMPOSER_PREFER_LOWEST_STABLE add --prefer-lowest-stable to update command Nov 22, 2014
@nicolas-grekas
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Nov 22, 2014

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
Copy link
Member

@naderman naderman commented Nov 26, 2014

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

@nicolas-grekas
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Nov 26, 2014

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

@naderman
Copy link
Member

@naderman naderman commented Nov 26, 2014

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
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Dec 2, 2014

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
Copy link
Contributor

@dbu dbu commented Dec 2, 2014

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.

@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:prefer-lowest-stable branch from a896606 to 98b254a Dec 13, 2014
@nicolas-grekas 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
Copy link
Member

@Seldaek Seldaek commented Dec 13, 2014

@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
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Dec 13, 2014

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
Copy link
Member

@Seldaek Seldaek commented Dec 13, 2014

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
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Dec 13, 2014

Cool, then we can merge as is?

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

This comment has been minimized.

@Seldaek

Seldaek Dec 13, 2014
Member

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

This comment has been minimized.

@nicolas-grekas

nicolas-grekas Dec 13, 2014
Author Contributor

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

This comment has been minimized.

@Seldaek

Seldaek Dec 13, 2014
Member

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

This comment has been minimized.

@Seldaek

Seldaek Dec 13, 2014
Member

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

@Seldaek
Copy link
Member

@Seldaek Seldaek commented Dec 13, 2014

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

@dbu
Copy link
Contributor

@dbu dbu commented Dec 13, 2014

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
Copy link
Member

@Seldaek Seldaek commented Dec 13, 2014

@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
Copy link
Contributor

@dbu dbu commented Dec 13, 2014

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
Copy link
Member

@Seldaek Seldaek commented Dec 13, 2014

Ah ok yes for sure :)

@nicolas-grekas
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Dec 13, 2014

prefer-lowest is now persisted in composer.lock

@alcohol
Copy link
Member

@alcohol alcohol commented Dec 13, 2014

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

@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:prefer-lowest-stable branch from f4fe6a7 to 7c2cade Dec 14, 2014
@nicolas-grekas
Copy link
Contributor Author

@nicolas-grekas nicolas-grekas commented Dec 14, 2014

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

@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:prefer-lowest-stable branch from 7c2cade to e9d2335 Dec 14, 2014
@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:prefer-lowest-stable branch from e9d2335 to e821ac2 Dec 14, 2014
@Seldaek
Copy link
Member

@Seldaek Seldaek commented Dec 14, 2014

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

Seldaek added a commit that referenced this pull request Dec 14, 2014
add --prefer-lowest and --prefer-stable to update command
@Seldaek Seldaek merged commit 901fd83 into composer:master Dec 14, 2014
1 check passed
1 check passed
continuous-integration/travis-ci The Travis CI build passed
Details
@nicolas-grekas nicolas-grekas deleted the nicolas-grekas:prefer-lowest-stable branch Dec 14, 2014
fabpot added a commit to symfony/symfony that referenced this pull request Dec 15, 2014
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.