Composer: Take symfony compatibility into account when suggesting changes

[petski]

Starting this discussion based on the request @rarkins made in #24723 (comment)

Symfony has multiple release branches. At the time of writing the 7.x releases are rolling releases and the 6.4.* releases are LTS (Long Term Support) releases.

If a developer chooses to follow the LTS branch, he/she installs symfony/flex and sets extra.symfony.require to the required version. This way, packages requireing other packages under the "Symfony umbrella" (more about that later) will be restricted to the constraint in extra.symfony.require.

See thiscomposer.json snippet as an example:

{
    "require": {
        "gedmo/doctrine-extensions": "^3.17",
        "symfony/flex": "^2",
        "symfony/framework-bundle": "6.4.*"
   },
   "extra": {
        "symfony": {
            "require": "6.4.*"
        }
    }
}

Package gedmo/doctrine-extensions has "symfony/cache": "^5.4 || ^6.0 || ^7.0" as a requirement. Because symfony/flex hooks into composer, the installed symfony/cache version will be the one compliant with 6.4.*.

Renovate doesn't have this logic on board, resulting in a PR with a (undesired) bump to a symfony/cache matching ^7.0.

Symfony superstar @nicolas-grekas explains what is considered to be under the "Symfony umbrella" here #24723 (comment)

The flex hook can be found here: https://github.com/symfony/flex/blob/2.x/src/PackageFilter.php#L104

I created a test repo which reproduces this issue at https://github.com/petski/renovate-31910.

If Renovate suggests a major Symfony bump (i.e. from 6.4.x to 7.x), extra.symfony.require should also be bumped accordingly.

[github-actions[bot]]

Hi there,

Get your discussion fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the minimal reproduction in your own repository.
5. Fill out the information in your repository's README.md.
6. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.

If you need help with running renovate on your minimal reproduction repository, please refer to our Running Renovate guide.
Good luck,

The Renovate team

[rarkins]

Please use the reproduction template above and make note of the instructions, e.g.

• Expected vs Observed behavior description
• Minimal dependencies
• Minimal config

[petski]

Done in https://github.com/petski/renovate-31910. Updated the first post/comment accordingly.

[rarkins]

Which of these two are you meaning?

1. Renovate should not update gedmo/doctrine-extensions to 3.17.1 because it's incompatible with your symfony settings, or
2. Renovate should update gedmo/doctrine-extensions to 3.17.1 but the symfony/flex version in the lock file must stay as-is?

[petski]

In that case, one could mimic symfony/flex's behavior by using the --with-feature composer has.

From the documentation:

--with=WITH  Temporary version constraint to add, e.g. foo/bar:1.0.0 or foo/bar=1.0.0 (multiple values allowed)

Confirmed to be working in my test repo:

$ docker run -i -t --rm -v $(pwd):/src -w /src composer:latest composer update --dry-run --no-plugins \
--with 'symfony/cache=6.4.*' \
--with 'symfony/var-exporter=6.4.*'

Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 1 update, 0 removals
  - Upgrading gedmo/doctrine-extensions (3.17.0 => v3.17.1)
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Upgrading gedmo/doctrine-extensions (3.17.0 => v3.17.1)
11 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found.

What needs to be done:

• Check if composer.json has symfony/flex part of the require. Continue with normal behavior if not.
• Check if composer.json has extra.symfony.require set. Continue with normal behavior if not.
• Retrieve the replace of https://packagist.org/packages/symfony/symfony.
  • Something like this curl -s 'https://repo.packagist.org/p2/symfony/symfony.json' | jq '.packages["symfony/symfony"][0].replace | keys'
• Append those packages to composer's --with argument, with the value of extra.symfony.require as constraint.

[rarkins]

I notice that there's about 60 replace keys. The composer command would be pretty long then?

[petski]

Not an issue per se, is it?

If that's a showstopper, one could run a patched/forked version of composer (under your control), with:

1. This logic built in.
2. The ability to add symfony/flex to the allow-list for plugins. (Keep in mind that symfony/flex can have another source-repository as the official repository. If so, this is still an attack-vector for untrusted code)

[rarkins]

I think I prefer your What needs to be done: suggestion more than these two suggestions. Are you interested in contributing it?

[petski]

Sorry to say no. My heart says yes, but my brains know this would not fit my schedule.

[petski]

I managed to get a workaround for this, by using composer's conflict feature.

In composer.json under the conflict key, I added the output of this script:

composer show --available --latest --format=json symfony/symfony '6.4.*' | jq '.replaces | with_entries(.value = "<6.4 || >=7.0")'

This mimics symfony/flex behavior.

Maintaining this can be a bit tedious though, so I think a more proper solution is still desired.

[rarkins]

Thanks. Summarizing for anyone finding this in future:

Immediately above you have a workaround available when scripts aren't enabled.

Earlier you proposed what seems like a good solution when scripts aren't enabled: #31910 (reply in thread). This could be spun out into a clean "Suggest an idea" discussion and converted to a feature request if anyone wants it.

Alternatively enabling scripts if the easiest solution, but not always possible.