Composer the process class relies on proc_open, which is not available on your php installation

My composer.json:

{
    "name": "maison-bible/prestashop",
    "description": "Prestashop Livre et plus",
    "repositories": [
        {
            "type": "vcs",
            "url": ":maisonbible/stripe-official.git"
        }
    ],
    "require": {
        "composer/installers": "^1.0.21",
        "202-ecommerce/stripe-official": "dev-lmeyer"
    },
    "authors": [
        {
            "name": "Societe Biblique de Geneve",
            "email": ""
        }
    ]
}

Output of composer diagnose:

Checking composer.json: WARNING
No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
Checking platform settings: OK
Checking git settings:
                                                                                
  [Symfony\Component\Process\Exception\RuntimeException]                        
  The Process class relies on proc_open, which is not available on your PHP installation.
                                                                                

diagnose

When I run this command:

I get the following output:

Loading composer repositories with package information
Installing dependencies [including require-dev] from lock file
Package operations: 1 install, 0 updates, 0 removals
  - Installing 202-ecommerce/stripe-official [dev-lmeyer 5939a51]:
                                                                                
  [Symfony\Component\Process\Exception\RuntimeException]                        
  The Process class relies on proc_open, which is not available on your PHP installation.

And I expected this to happen:

I expected to be able to run composer install without issue.

Is there a way to circumvent the problem of proc_open not being available ? If yes, what should I do ?

I don't think this is possible. Composer relies heavily on being able to run commands.

Alternatively running composer install --prefer-dist might make it work if you're lucky but yes generally speaking we do require external processes for a lot of things.

Understandably, enabling proc_open would be the preferred solution.

However I'm finding a composer install on shared hosting out of my control to work fine if it can't find an unzip command. It then falls back to using ZipArchive/Zip extension, which has its own drawbacks that the output warns about, but does not require proc_open to successfully install packages.

[Side note: In this case the only thing I'm doing is a composer install from a lockfile with a couple of options [prefer dist, optimise autoloader] so that doesn't seem to require any other external processes [or those are already skipped if proc_open isn't available]. It's just extracting the archives that's affected in my use case.]

@Seldaek: do you think adding a && \function_exists['proc_open'] check here has a chance of getting accepted into Composer so it falls back to ZipArchive [or just fails if it's not going to be able of unzipping]?

Alternatively, perhaps adding that check in the extractWithSystemZip method may be more appropriate as that's already supposed to fallback to ZipArchive, but doesn't because it fails to consider if proc_open is available. I'm not sure why that isn't already falling back to ZipArchive anyway when running the Process fails because of proc_open..

I could prepare a quick PR, but as I've not contributed to Composer before and probably lack a bunch of context, I would also be happy to pay someone on the team/a regular contributor for an hour of their time instead...

Yeah that makes sense, we want to support some basic install code-path without proc_open for sure, I can do the fix quickly.

That would be amazing, thanks. Also for a very fast response!

How can I best pay you for your time? I see the Github Sponsors can take a one-time donation on the Composer org, does that work?

Sure sponsoring on the composer org is Sure sponsoring on the composer org is a good place, thanks!

60fe670 should fix it.

@Seldaek Just tested the latest snapshot on 2 different environments without proc_open [one with unzip, one without] and it's working brilliantly. Thank you!

Will send a donation [from @modmore] in a bit. :]

For some reason the sponsoring didn't go through the first time, so I've just added it again, which should get to you on September 28th.