What guardrails need to be in place in order to run Composer without proc_open?

[effulgentsia]

In #9253 (comment), @Seldaek said:

we want to support some basic install code-path without proc_open for sure

Thank you for that!

For Drupal, we're working on adding an Automatic Updates feature and an install-packages-from-the-UI feature. Both involve the Drupal website running Composer commands (update and require), on itself, in production. We're using https://github.com/php-tuf/composer-stager to make that more sane than it might first sound. This is primarily geared towards small sites, typically on cheap shared hosting, who do not have or need a dev to prod deployment process. Some of this target audience uses hosts that disable proc_open.

I'd like to ask for input from Composer maintainers as to what conditions would need to be in place for the sites without proc_open to be able to use these features reliably? The ones that come immediately to mind are:

• minimum-stability: alpha
• preferred-install: dist
• Not using any 3rd party plugins that execute processes

With the above in place, how likely is it that no calls to proc_open will be needed? Are there common conditions where despite the above constraints that Composer would need to call a git command or some other process? Thanks for any insight!

[Seldaek]

I think that should cover it.. but to be honest I might well be missing something :)

[stof]

Note that preferred-install: dist won't help if the package you try to install does not provide a dist (any package hosted on github or gitlab.com will have it thanks to those platforms. Packages hosted on a custom Gitlab instance using the vcs repository type will have it only if gitlab-domains is configured to include the domain of that custom instance)

[github-actions]

This issue has been automatically marked Stale and will be closed in 15 days if no further activity happens.

[stof]

Another requirement: having ext-zip so that archives can be decompressed in PHP instead of using a CLI tool.