Select packages when installing extensions for a PHP project

[asgrim]

Discussed in #478

^{Originally posted by Thahun January 7, 2026}

TLDR from discussion; there is no way to specify which package to install when using pie install --allow-non-interactive-project-install in a PHP project if multiple packages match.

Proposed solution & full write-up

At the moment, installing extensions for a PHP project is a little janky. This is because in a PHP project's composer.json, the extensions required are listed as ext-<ext_name> ("Extension Name" with an ext- prefix, e.g. example_pie_extension), but in PIE, we refer to extensions by their "Package Name" (e.g. asgrim/example-pie-extension to avoid ambiguity. This is because there may be a fork that someone wishes to install, instead of the primary extension.

When pie install is run in the CWD of a PHP project, it loads the composer.json/lock to determine all extensions required, and checks them one by one. If one is missing:

• In interactive mode, you are always prompted for which package to pick, even if there is one choice. This gives dev control about which package they meant
• In non-interactive mode (CI, Docker build, etc.); PIE will refuse
• In non-interactive mode with --allow-non-interactive-project-install flag provided (dev should understand the risks here!):
  • If there is one choice, PIE will automatically install the matched package
  • If there is more than one choice, PIE will fail; we cannot automatically resolve the package

The proposal is to:

• Deprecate and make a no-op the --allow-non-interactive-project-install flag (if provided, it will print out information about the change)
• Add a new flag for consumers to explicitly define packages for each extension, e.g. pie install --select ext-redis=phpredis/phpredis --select ext-foo=asgrim/foo
  • When running this, if an extension is encountered that is not installed, and not defined (e.g. ext-bar is required), it will fail, even if only one package matches
  • If an extension is encountered that is not installed and a --select has been provided, it will use that (e.g. ext-foo will resolve to asgrim/foo)
  • If an extension is encountered that is installed, the --select is ignored
• Keep interactive mode the same; the user will be prompted for each package that is missing; unless a --select has been passed for that package, in which case that will be used, but that is less likely to occur

The benefit here is clear: the end user has full control over which packages are installed for each extension. The non-interactive scenarios where this is needed (e.g. in CI, in a Dockerfile build, etc.), the user should not need to type these --select <def> flags out all the time, since it would be in a CI definition or Dockerfile etc, so there is only a small initial burden, but for much greater control and safety.

Future enhancements could be to define this in some kind of configuration file. This is left out of scope explicitly for now; I want to get this working in its basic form, then we can iterate later.

One "known issue" with this approach: it is not possible currently to specify configure flags for extensions installed this way. That is already the case with --allow-non-interactive-project-install flag anyway, so there is no reduction in functionality. That could be addressed in the configuration file mentioned.

[rvanlaak]

Then it would be preferable to not remove the deprecation of the flag before the feature for installation through a config file is added. We now have unattended install fully working through the ext-*definitions in our composer.json, which imho would be a great place to have modules defined (hence in a more specific format). Dependabot/Renovate already support these files for easy and maintainable version locking.

[asgrim]

@rvanlaak Sorry, unfortunately, you will need to add --select <def> definitions for your pie install non-interactive commands, as described above; this is to ensure you are selecting the correct package you meant to (and not something else you did NOT expect). Unfortunately, --allow-non-interactive-project-install must be turned into a no-op as the way it works is less than idea.

Edit, expanding on this;

The fact is; even if "unattended install" is working now, there is no guarantee it will continue working anyway. Lets say you depend on ext-foo in your composer.json; right now this might work because there is only one ext-foo match. However, if someone else creates a compatible ext-foo, your unattended install will break anyway, and you will be stuck with a problem (you'd have to manually install your desired ext-foo package first, then run pie install).

Adding the --select <def> for all packages means you will always get the packages you expect, and closes that gap between PIE giving a "best guess" (at the moment) and "what you actually want" (what this improvement will provide)

[rvanlaak]

Yes a deprecation is fine, and understand that the direction package selection is moving to is the way to go. But, would be great that the removal of the flag would happen after that installation through a config format gets released.

[asgrim]

Providing --select <def> list by params will be the only initially supported mechanism for this; I've explained the reasons for that; a configuration file is a possible future improvement, but at the moment, that has not been considered.

[Ninos]

@asgrim thx for the issue. Would more love the idea expanding composer.json instead of using command flags. Advantages:

• better automatisation
• easier version tagging & upgrade (e.g. using Renovate)
• possibility defining individual build flags (per extension)

We could use the extra property of the composer.json, see also:
https://getcomposer.org/doc/04-schema.md#extra

Could look something like this:

{
    "extra": {
        "pie": {
            "someGenericSettings": "whichMakesSense",
            "extension": {
                "someExt": "*",
                "anotherExt": {
                    "version": "^1.0",
                    "flag": {
                        "someFlag": null,
                        "anotherFlag": "flagValue"
                    }
                }
            }
        }
    }
}

Or may expand the schema to our needs (pie property on same level as extra):
https://getcomposer.org/schema.json

I think expanding the json schema would be the cleanest solution. I could create a MR for the composer project. Otherwise using the extra property will also not hurt :D
Let me know 👼

[asgrim]

@Ninos as I mentioned above, and as we already discussed in #478 there is scope for that, but I have explicitly ruled that out of the initial for this to keep things simple. There is actually limited benefit to having a configuration file for this purpose; the versions used for extensions to be installed are already pulled from composer.json. The only benefit is being able to define configure flags. But please note, I did already address all of this in the original issue description. Please read it!

[Ninos]

Ah I see, thought this will get the new alternative. Thx for clarification! :)

[asgrim]

For further context; I don't want to get hung up on bikeshedding the best configuration approach; instead, we'll do a basic functionality that solves the problem properly, as --allow-non-interactive-project-install really isn't fit for purpose IMO. Had the right intentions, but using --select <def> will solve it better, albeit in a slightly more verbose way. But the verbosity should not be an issue, since it would typically only be used in CI / Dockerfiles etc.