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

"compose require foo/bar" ignores the existing constraints when selecting the default version #6869

Closed
nicolas-grekas opened this Issue Dec 4, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@nicolas-grekas
Contributor

nicolas-grekas commented Dec 4, 2017

Variant 1: run composer create-project symfony/skeleton on PHP 7.0 => fails because it tells the skeleton "^4" needs 7.1 (but "^3" would be fine)

Variant 2: run:

  • composer create-project symfony/skeleton demo ^3
  • cd demo
  • composer require symfony/var-dumper

Fails because composer select "^4" for the component, which conflicts with symfony/lts ^3 (but ^3 would be fine)

Saw this more that 10 times today (training session.)

@nicolas-grekas nicolas-grekas changed the title from "compose require foo.bar" ignores the existing constraints when selecting the default version to "compose require foo/bar" ignores the existing constraints when selecting the default version Dec 4, 2017

@nicolas-grekas

This comment has been minimized.

Show comment
Hide comment
@nicolas-grekas

nicolas-grekas Dec 4, 2017

Contributor

Se e.g. symfony/symfony#25314 for a user report.

Contributor

nicolas-grekas commented Dec 4, 2017

Se e.g. symfony/symfony#25314 for a user report.

@curry684

This comment has been minimized.

Show comment
Hide comment
@curry684

curry684 Dec 4, 2017

Contributor

We've discussed this issue before, problem is that it's incredibly hard to solve. Only rock solid solution is to have an actual solver run with * as the package constraint, and then extract what it came up with. That would make it annoyingly slow, yet all other solutions would just be hacks with their own issues and edge cases.

Contributor

curry684 commented Dec 4, 2017

We've discussed this issue before, problem is that it's incredibly hard to solve. Only rock solid solution is to have an actual solver run with * as the package constraint, and then extract what it came up with. That would make it annoyingly slow, yet all other solutions would just be hacks with their own issues and edge cases.

@nicolas-grekas

This comment has been minimized.

Show comment
Hide comment
@nicolas-grekas

nicolas-grekas Dec 5, 2017

Contributor

@curry684 sure. Yet I think we should try harder, this is hurting DX significantly.

A possible path for a fix could be to start with "*", then resolve the deps as done already, and patch the resulting composer.json to turn the "*" into a more tailored version constraint.

Contributor

nicolas-grekas commented Dec 5, 2017

@curry684 sure. Yet I think we should try harder, this is hurting DX significantly.

A possible path for a fix could be to start with "*", then resolve the deps as done already, and patch the resulting composer.json to turn the "*" into a more tailored version constraint.

@curry684

This comment has been minimized.

Show comment
Hide comment
@curry684

curry684 Dec 5, 2017

Contributor

That's sort of what I was trying to type on my mobile yeah :)

The problem is with reciprocality mainly. It's not that hard, when adding a new package, to check all currently installed packages for their dependencies, and simply walk down the possible versions of the new package to find one that doesn't violate constraints. This is more or less how the why-not command works. Except that that command inherently has the exact shortcoming that makes this issue so hard to solve as well - it cannot predict the other way around whether it's own (indirect) dependencies would cause a change in the existing installed packages, therefore invalidating the prime choice. It is therefore (currently) not possible to run why-not on a package that is not yet installed, which is a pretty stupid shortcoming.

Like I said, there are some half-assed solutions that would make the current situation slightly better, but the only real solution is a full solver run based on "new/package:*". And that's not going to be fast, especially not when adding a ton of packages at once.

Contributor

curry684 commented Dec 5, 2017

That's sort of what I was trying to type on my mobile yeah :)

The problem is with reciprocality mainly. It's not that hard, when adding a new package, to check all currently installed packages for their dependencies, and simply walk down the possible versions of the new package to find one that doesn't violate constraints. This is more or less how the why-not command works. Except that that command inherently has the exact shortcoming that makes this issue so hard to solve as well - it cannot predict the other way around whether it's own (indirect) dependencies would cause a change in the existing installed packages, therefore invalidating the prime choice. It is therefore (currently) not possible to run why-not on a package that is not yet installed, which is a pretty stupid shortcoming.

Like I said, there are some half-assed solutions that would make the current situation slightly better, but the only real solution is a full solver run based on "new/package:*". And that's not going to be fast, especially not when adding a ton of packages at once.

@nicolas-grekas

This comment has been minimized.

Show comment
Hide comment
@nicolas-grekas

nicolas-grekas Dec 5, 2017

Contributor

Dunno if that's applicable, but an idea could be to resolve the version to "auto".
This would be an alias to "*" from the solver POV.
But once the solver has ran, "auto" would then be replaced by a regular semver constraint, before the composer.lock file is written.
@Seldaek @naderman would that make sense?

Contributor

nicolas-grekas commented Dec 5, 2017

Dunno if that's applicable, but an idea could be to resolve the version to "auto".
This would be an alias to "*" from the solver POV.
But once the solver has ran, "auto" would then be replaced by a regular semver constraint, before the composer.lock file is written.
@Seldaek @naderman would that make sense?

@nicolas-grekas

This comment has been minimized.

Show comment
Hide comment
@nicolas-grekas

nicolas-grekas Dec 6, 2017

Contributor

FYI, Flex-based workaround here: symfony/flex#231 (only fits symfony/* packages, not a generic solution.)

Contributor

nicolas-grekas commented Dec 6, 2017

FYI, Flex-based workaround here: symfony/flex#231 (only fits symfony/* packages, not a generic solution.)

fabpot added a commit to symfony/flex that referenced this issue Dec 7, 2017

feature #231 Stick to framework-bundle's version by default (nicolas-…
…grekas)

This PR was merged into the 1.0-dev branch.

Discussion
----------

Stick to framework-bundle's version by default

Works around composer/composer#6869

Commits
-------

be325e8 Stick to framework-bundle's version by default

@Seldaek Seldaek added the Feature label Dec 18, 2017

@Seldaek Seldaek added this to the Nice To Have milestone Dec 18, 2017

@nicolas-grekas

This comment has been minimized.

Show comment
Hide comment
@nicolas-grekas

nicolas-grekas Aug 23, 2018

Contributor

Closing as we don't this need anymore and this is kinda edge-case.

Contributor

nicolas-grekas commented Aug 23, 2018

Closing as we don't this need anymore and this is kinda edge-case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment