Every "composer install" run fetches recipes from GitHub

[glaubinix]

I noticed that Composer projects using Symfony Flex try to fetch the recipe files from GitHub on every composer install command. This happens because Flex registers truncatePackages as PluginEvents::PRE_POOL_CREATE. The PRE_POOL_CREATE event is triggered on both install and update commands. Is this intentional? Based on what the truncatePackages method does - filter out packages from the pool of available packages - this rather sounds like it shouldn't happen on composer install.

Accessing GitHub during composer install can also lead to issues during deployment where access to GitHub isn't expected, e.g. for setups that use a Private Composer repository like Satis or Private Packagist.

Example composer install output

composer install -vvv
Running 2.8.6 (2025-02-25 13:03:50) with PHP 8.2.27 on Darwin / 24.3.0
Reading ./composer.json (/Users/dummy/Projects/test/composer.json)
Loading config file /Users/dummy/.composer/config.json
Loading config file /Users/dummy/.composer/auth.json
Loading config file ./composer.json (/Users/dummy/Projects/test/composer.json)
Checked CA file /opt/homebrew/etc/ca-certificates/cert.pem: valid
Executing command (/Users/dummy/Projects/test): 'git' 'branch' '-a' '--no-color' '--no-abbrev' '-v'
Reading /Users/dummy/.composer/composer.json
Loading config file /Users/dummy/.composer/config.json
Loading config file /Users/dummy/.composer/auth.json
Loading config file /Users/dummy/.composer/composer.json (/Users/dummy/.composer/composer.json)
Loading config file /Users/dummy/.composer/auth.json
Reading /Users/dummy/.composer/auth.json
Reading /Users/dummy/Projects/test/vendor/composer/installed.json
Reading /Users/dummy/.composer/vendor/composer/installed.json
Loading plugin Http\Discovery\Composer\Plugin (from php-http/discovery)
Loading plugin PackageVersions\Installer (from composer/package-versions-deprecated)
Loading plugin Symfony\Flex\Flex (from symfony/flex)
Loading plugin Symfony\Component\Runtime\Internal\ComposerPlugin (from symfony/runtime)
Reading ./composer.lock (/Users/dummy/Projects/test/composer.lock)
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Reading ./composer.lock (/Users/dummy/Projects/test/composer.lock)
> pre-pool-create: Symfony\Flex\Flex->truncatePackages
Reading /Users/dummy/Library/Caches/composer/repo/flex/symfony-recipes-flex-main-index.json from cache
Reading /Users/dummy/Library/Caches/composer/repo/flex/symfony-recipes-contrib-flex-main-index.json from cache
Downloading https://raw.githubusercontent.com/symfony/recipes/flex/main/index.json
Downloading https://raw.githubusercontent.com/symfony/recipes-contrib/flex/main/index.json
[304] https://raw.githubusercontent.com/symfony/recipes/flex/main/index.json
[304] https://raw.githubusercontent.com/symfony/recipes-contrib/flex/main/index.json
Built pool.
Generating rules
Resolving dependencies through SAT
Looking at all rules.

[Trusted97]

In addition to what @glaubinix mentioned, this behavior is also limiting when using private recipes from a GitLab repository. I noticed that there is a dedicated class for fetching recipes from GitHub, but nothing similar for GitLab. If needed, I’d be happy to open a pull request to add this functionality.

[nicolas-grekas]

During a composer install, prePoolCreate is triggered, and at that point, we fetch the list of symfony/* packages via an API call to narrow down the possible versions (based on extra.symfony.require).

BUT, as you describe, this shouldn’t happen during an install — it only makes sense during an update.

I was wondering why Composer invokes the SAT solver during install, and I understand now it’s to verify the current runtime — mainly PHP extensions.

My question is: how can I tell on flex's end that it’s doing this just for runtime validation, and not for a real update?

I thought of checking the list of repositories and doing nothing if there’s no repository of type ComposerRepository — would that be a valid approach?

Or is there a more mainstream / built-in way to detect this?

Also, I noticed that PoolOptimizer is created in one case but not in the other, but there’s no API to detect that difference directly.

/cc @Seldaek in case you have any ideas

[Seldaek]

on PRE_POOL_CREATE event, call $event->getRequest()->isPackageLocked() and if the package is locked leave it alone I'd say.

[nicolas-grekas]

Thanks for the hint @Seldaek
Fixed in #1048