Locking with incompatible constraints

[thewilkybarkid]

Similar to #412, which resolved cases where a package doesn't exist in the extra.symfony.require constraint, I'm trying to have one package not match the constraint, eg:

{
    "require": {
        "symfony/framework-bundle": "^4.0",
        "symfony/translation": "^4.1",
    },
    "extra": {
        "symfony": {
            "require": "~4.0.0"
        }
    }
}

which results in

    - The requested package symfony/translation ^4.1 exists as symfony/translation[4.0.x-dev, v4.0.0, v4.0.0-BETA1, v4.0.0-BETA2, v4.0.0-BETA3, v4.0.0-BETA4, v4.0.0-RC1, v4.0.0-RC2, v4.0.1, v4.0.10, v4.0.11, v4.0.12, v4.0.13, v4.0.14, v4.0.15, v4.0.2, v4.0.3, v4.0.4, v4.0.5, v4.0.6, v4.0.7, v4.0.8, v4.0.9] but these are rejected by your constraint.

Would you expect this to be possible?

(Refs libero/content-api-bundle#17 (comment))

[nicolas-grekas]

Nope, that's not possible as that's conflicting with the very semantics of extra.symfony.require

[Taluu]

I'd like to reopen this issue and discuss. IMO, if a package is not *, the extra.symfony.require shouldn't mess with it (I currently need to install 4.4@dev of the http client, but can't due to that... I can remove the require but "meh", I would need to update all my packages by hand :/)

[stof]

The whole point of extra.symfony.require is that it is filtering the composer metadata loaded from Packagist to remove other versions.
It is not changing your constraints. And switching to apply it only to * constraint would break its usage: many components you use in your project are not root requirements, but dependencies of other packages (higher-level components, FrameworkBundle, packs, etc...), for which the requirement will never be *.
And it would also break the usage of Flex as a way for open-source packages to force CI to run on specific versions (which is currently possible, and the reason why we deprecated the symfony/lts package).

[nicolas-grekas]

to add to what stof just said and provide you with a possible solution:

I currently need to install 4.4@dev of the http client, but can't due to that

you can set extra.symfony.require to ^4.3 and that will allow 4.4@dev too

[Taluu]

Hum, then if I need 5.0 for some reasons (let's say end of november), but stay on on a lower version, could ^4.0 || ^5.0 pass too ?

If it does, then nevermind. Got confused with an old issue that stated that to pass the validation of the composer validate --check, it shouldn't complain when using * versions. :}

[stof]

Hum, then if I need 5.0 for some reasons (let's say end of november), but stay on on a lower version

I don't understand what you mean.

[Taluu]

{
    "require": {
        "symfony/notifier": "5.0@dev",
        "symfony/framework-bundle": "*"
    },
    "extra": {
        "symfony": {
            "require": "^4.3 || ^5.0"
        }
    }
}

something along those lines (took the notifier but can be anything from symfony's)

[nicolas-grekas]

If you lock yourself to ^4.3, you will still be able to install new components that are only found in 5.*

[Taluu]

Then replace notifier with messenger for example (see my edit). :}

[stof]

Well, that will allow you to install messenger 5 and stable 4.3 versions of other components (assuming that component requirements agree with that). but as soon as there is a stable release of other components, they won't stay on 4.3 but upgrade too (as that's allowed by the filter).

[Taluu]

That's what I wanted to know, and so works for me then (the question was if I could have a real semver notation on that part, including || support to target multiple major versions / complex constraints)

[stof]

Flex relies on composer to handle these. So anything supported by composer/semver will work for the constraint.