Support non proc_open composer

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.

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.

So I tested out the idea in #14 locally and it seems to work. I'm attaching the tiny proof-of-concept module I created to implement this.

If we implement this in core (doesn't seem like it'd be too hard), then combined with the addition of direct-write mode ✨ Make Package Manager more friendly to local development by allowing stages to operate directly on the codebase in some situations Active , it would be possible to do some Package Manager stuff without needing Composer to be preinstalled on the system. It could be a runtime dependency of the project.

@catch pointed out in Slack that doing this would not necessitate adding composer/composer to core's runtime dependencies. Package Manager would keep trying to use an external binary, unless it detects composer/composer in the local code base, in which case it would try to use that instead.

This means we could add composer/composer as a runtime dependency of, say, drupal/cms (or maybe even core's project templates), but it would not actually need to be a true core dependency.

I like the idea of this being a fallback. Re-titling to clarify that.

Been thinking more about this. Now that I have a working patch, I am actually not sure if we want to do this at all, for a few reasons:

• Having proc_open disabled seems to be, to at least some degree, an edge case. We haven't heard this complaint too much. We get far more complaints about Composer and rsync not being auto-detectable, which is something we are trying to ameliorate in other issues.
• We are very clear here that proc_open is by far the best way to run Composer, since it prevents weird behavior and the heightened risk of OOM and timeout errors. We already have documentation in our hook_help that says what to do if proc_open is disabled.
• If you have proc_open disabled, not only can you not use Composer; you can't use rsync either, and rsync is still required, in almost all cases, for Package Manager to work. It doesn't make any sense to allow a fallback method of executing Composer without having something similar for rsync -- but that brings us back to the "PHP file syncer" days, when Composer Stager tried to reimplement the relevant parts of rsync in PHP, and we ended up throwing out all that work (and it was a shit ton of work). Even if we ended up using a file syncer that was not rsync (like xcopy, for example), it'd still need proc_open.
• This would be yet another example of the "having more than one way to do things" syndrome that core has historically suffered from. Maybe we don't want that.
• The implementation (using a test harness as an execution driver) is clever, and we could rely on it, but it is kind of...sideways. I doubt Symfony would be expecting anyone to use their test harness for this purpose, so we are at slightly higher risk of breaking changes in Symfony Console.
• I didn't spend too much time on this, and I am okay throwing out my work here if it doesn't, ultimately, make strategic and technical sense overall.

I therefore leave this one up to @catch and other framework managers. Is there really a benefit to implementing this, or is it really a poison pill in disguise?

So composer/composer updates make this a bit frightening. But having to re-implement rsync tips this into 'is it worth it?' territory, and combined with the other points, I don't see a good reason to do this. At least we have good documentation for why not. Going to close this as won't fix (briefly discussed with @phenaproxima in slack too), but also adding credits.