- 🇬🇧United Kingdom catch
Moving this to the core queue.
I have no idea how widespread disabling proc_open on shared hosting (or other hosting environments) is in 2025, but I think it would be useful to try to get data from at least a few major hosting providers.
Depending on that, and reports like the original one here from people trying to run automatic_updates/project_browser on hosting without proc_open support, we could then consider what to do.
It would probably require a fallback that bypasses Symfony's Process component altogether - but unless we re-implement the process component or swap out some classes, that probably means calling composer API functions directly instead of via the cli.
- 🇺🇸United States phenaproxima Massachusetts
An idea: I have no idea if this would actually work or be remotely feasible, but we can't use proc_open, then maybe we can take advantage of the fact that Composer is itself built on Symfony components. We could perhaps use Symfony Console's command testing harness to invoke the various Composer commands CLI-style, but without creating an actual process. This means we'd need to bring in Composer's PHP code base as a runtime dependency, but wouldn't necessarily need the Composer binary itself.