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

Symfony packages not fully restricted to major version (4.4.*) #982

Open
Itebo-E-Services-Development opened this issue Jun 16, 2023 · 4 comments

Comments

@Itebo-E-Services-Development
Copy link

Itebo-E-Services-Development commented Jun 16, 2023

Hello 👋

Currently we are in the process of upgrading an old symfony project of ours from 3.4 to 5.4/6.x and already made the transition from the old directory structure to the newer one from flex.

As we are upgrading from 3.4 to 4.4 to see all deprecations for that major version, I noticed that not all dependencies from symfony/* are restricted to 4.4.* or 4.* even, as symfony/var-exporter is installed with version 5.4.21.

composer.json

{
...
    "require": {
        "php": ">=7.0.8",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "components/jquery": "1.11.3",
        "doctrine/doctrine-bundle": "^1.6",
        "doctrine/orm": "^2.5",
        "knplabs/knp-snappy-bundle": "^1.4",
        "sensio/framework-extra-bundle": "^5.0.0",
        "symfony/asset": "4.4.*",
        "symfony/console": "4.4.*",
        "symfony/dotenv": "4.4.*",
        "symfony/flex": "^1.3.1",
        "symfony/form": "4.4.*",
        "symfony/framework-bundle": "4.4.*",
        "symfony/monolog-bundle": "^3.1.0",
        "symfony/polyfill-apcu": "^1.0",
        "symfony/security": "4.4.*",
        "symfony/security-bundle": "4.4.*",
        "symfony/swiftmailer-bundle": "^3.5",
        "symfony/twig-bundle": "4.4.*",
        "symfony/validator": "4.4.*",
        "symfony/yaml": "4.4.*",
        "twig/twig": "^1.0||^2.0"
    },
    "require-dev": {
        "symfony/maker-bundle": "^1.29",
        "symfony/phpunit-bridge": "^3.0",
        "symfony/web-profiler-bundle": "4.4.*"
    },
    "config": {
        "preferred-install": {
            "*": "dist"
        },
        "sort-packages": true,
        "allow-plugins": {
            "symfony/flex": true
        }
    },
    "autoload": {
        ...
    },
    "autoload-dev": {
        ...
    },
    "replace": {
        "paragonie/random_compat": "2.*",
        "symfony/polyfill-ctype": "*",
        "symfony/polyfill-iconv": "*",
        "symfony/polyfill-php70": "*",
        "symfony/polyfill-php56": "*"
    },
    "scripts": {
        [...]
    },
    "conflict": {
        "symfony/symfony": "*"
    },
    "extra": {
        "symfony": {
            "allow-contrib": false,
            "require": "4.4.*"
        }
    }
}

Output of composer update "symfony/*" swiftmailer/swiftmailer --dry-run (swiftmailer needed because of dependencies, will migrate to symfony/mailer next):

Loading composer repositories with package information
Restricting packages listed in "symfony/symfony" to "4.4.*"
Updating dependencies
Lock file operations: 13 installs, 34 updates, 3 removals
  - Removing psr/simple-cache (1.0.1)
  - Removing symfony/class-loader (v3.4.47)
  - Removing symfony/translation (v3.4.47)
  - Locking egulias/email-validator (3.2.6)
  - Upgrading swiftmailer/swiftmailer (v5.4.12 => v6.3.0)
  - Upgrading symfony/asset (v3.4.47 => v4.4.46)
  - Upgrading symfony/cache (v3.4.47 => v4.4.48)
  - Locking symfony/cache-contracts (v2.5.2)
  - Upgrading symfony/config (v3.4.47 => v4.4.44)
  - Upgrading symfony/console (v3.4.47 => v4.4.49)
  - Upgrading symfony/debug (v3.4.47 => v4.4.44)
  - Upgrading symfony/dependency-injection (v3.4.47 => v4.4.49)
  - Upgrading symfony/doctrine-bridge (v3.4.47 => v4.4.48)
  - Upgrading symfony/dotenv (v3.4.47 => v4.4.37)
  - Locking symfony/error-handler (v4.4.44)
  - Upgrading symfony/event-dispatcher (v3.4.47 => v4.4.44)
  - Locking symfony/event-dispatcher-contracts (v1.1.13)
  - Upgrading symfony/filesystem (v3.4.47 => v4.4.42)
  - Upgrading symfony/finder (v3.4.47 => v4.4.44)
  - Upgrading symfony/form (v3.4.47 => v4.4.48)
  - Upgrading symfony/framework-bundle (v3.4.47 => v4.4.49)
  - Locking symfony/http-client-contracts (v2.5.2)
  - Upgrading symfony/http-foundation (v3.4.47 => v4.4.49)
  - Upgrading symfony/http-kernel (v3.4.49 => v4.4.50)
  - Upgrading symfony/inflector (v3.4.47 => v4.4.44)
  - Upgrading symfony/intl (v3.4.47 => v4.4.47)
  - Upgrading symfony/maker-bundle (v1.29.2 => v1.39.1)
  - Locking symfony/mime (v4.4.47)
  - Upgrading symfony/monolog-bridge (v3.4.47 => v4.4.43)
  - Upgrading symfony/monolog-bundle (v3.6.0 => v3.8.0)
  - Upgrading symfony/options-resolver (v3.4.47 => v4.4.44)
  - Locking symfony/polyfill-intl-idn (v1.27.0)
  - Locking symfony/polyfill-intl-normalizer (v1.27.0)
  - Locking symfony/polyfill-php73 (v1.27.0)
  - Locking symfony/polyfill-php80 (v1.27.0)
  - Locking symfony/polyfill-php81 (v1.27.0)
  - Upgrading symfony/process (v3.4.47 => v4.4.44)
  - Upgrading symfony/property-access (v3.4.47 => v4.4.44)
  - Upgrading symfony/routing (v3.4.47 => v4.4.44)
  - Upgrading symfony/security (v3.4.49 => v4.4.50)
  - Upgrading symfony/security-bundle (v3.4.48 => v4.4.50)
  - Upgrading symfony/swiftmailer-bundle (v2.6.7 => v3.5.4)
  - Locking symfony/translation-contracts (v2.5.2)
  - Upgrading symfony/twig-bridge (v3.4.47 => v4.4.49)
  - Upgrading symfony/twig-bundle (v3.4.47 => v4.4.41)
  - Upgrading symfony/validator (v3.4.47 => v4.4.48)
  - Upgrading symfony/var-dumper (v3.4.47 => v4.4.47)
  - Locking symfony/var-exporter (v5.4.21)
  - Upgrading symfony/web-profiler-bundle (v3.4.47 => v4.4.47)
  - Upgrading symfony/yaml (v3.4.47 => v4.4.45)
Installing dependencies from lock file (including require-dev)

This would be of course because of the package symfony/cache:4.4.48 with its requirement for symfony/var-exporter: ^4.2|^5.0, validated by running composer depends symfony/var-exporter after running the update. This can also be reproduced when just creating a new skeleton project with composer create-project symfony/skeleton:4.4.*.

Apparently, flex looks at the dependency and picks the highest version possible (5.4.21 in this case).

Now my question is: is this intended behaviour, a bug or something I'm missing here?

I expected all packages symfony/* to be limited to 4.4.* from what I understood how flex works, so I am just wondering.
At first, I thought this to be related to issues #971/#1181, but that problem was fixed some time ago.
From reading some of the source code of this plugin I got the impression, that the contents of the index.json from the flex recipe is relevant for this, but couldn't really figure out how.

Thanks to anyone being able to shed some light on this.

@amici
Copy link

amici commented Nov 30, 2023

I see the same issue while running Symfony v5.4 - the symfony/var-exporter is not honoring the Symfony restriction to 5.4.* and instead it loads the v6.3.*. Specifically, with v5.4.32, symfony/var-exporter loaded is v.6.3.6.

My symfony restrictions are like this

    "extra": {
        "symfony": {
            "allow-contrib": true,
            "require": "5.4.*",
            "docker": true
        }
    },

@GromNaN
Copy link
Member

GromNaN commented Dec 2, 2023

@amici do you have the symfony/flex plugin installed and allowed? Can you provide a reproducer with a composer.json.

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Dec 2, 2023

I don't have a link but IIRC we did this on purpose to allow installing recent Doctrine versions (that require a recent VarExporter) together with Symfony 5.4 (or 4.4 in your case).

@amici
Copy link

amici commented Dec 12, 2023

@amici do you have the symfony/flex plugin installed and allowed? Can you provide a reproducer with a composer.json.

Yes, I do have the symfony/flex running, v2.4.2. I'm not sure what do you mean by "allowed".
I will try in next days to get a reproducer, but I need to shorten my composer.json since it has a lot of things.

Unless, as @nicolas-grekas mentioned in earlier ticket - it was actually done on purpose, to allow the recent Doctrine versions to be installed. Then there's no point in reproducing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants