Dep command fails to run with Composer 2.2 and PHP7.4, Ubuntu 18.04

[mbtreetime]

• Deployer version: 7.0.0-rc3
• Deployment OS: Ubuntu 18.04
• Composer: 2.2
• PHP: 7.4.27

Running dep or vendor/bin/dep

PHP Fatal error:  Namespace declaration statement has to be the very first statement or after any declare call in the script in /var/www/site/vendor/bin/dep on line 13
PHP Stack trace:
PHP   1. {main}() /var/www/site/vendor/bin/dep:0
PHP   2. include() /var/www/site/vendor/bin/dep:92

Fatal error: Namespace declaration statement has to be the very first statement or after any declare call in the script in /var/www/site/vendor/bin/dep on line 13

Call Stack:
    0.0002     417344   1. {main}() /var/www/site/vendor/bin/dep:0
    0.0004     437928   2. include('/var/www/site/vendor/deployer/deployer/bin/dep') /var/www/site/vendor/bin/dep:92

• Composer: 2.1.14

In composer 2.1 it seems that vendor/bin/dep is a symbolic link dep -> ../deployer/deployer/bin/dep, but in composer 2.2 it copies the dep file to vendor/bin

It seems to work with PHP8 php8.0 vendor/bin/dep but not with 7.4 php7.4 vendor/bin/dep

[gjuric]

This is probably related, so I will post it here. When running deployer/dist with PHP 8.0 installed with Composer 2.2 I get the following Warnings:

PHP Warning:  Constant  already defined in ...vendor/deployer/dist/dep on line 5

Warning: Constant  already defined in ...vendor/deployer/dist/dep on line 5

If I require deployer/deployer instead of deployer/dist there is no warning.

[martijngastkemper]

• Deployer version: 7.0.0-rc3
• Deployment OS: Ubuntu 20.04
• Composer: 2.2.1
• PHP: 7.4.26

I've the same error:

PHP Fatal error:  Namespace declaration statement has to be the very first statement or after any declare call in the script in /home/runner/work/repo/app/vendor/bin/dep on line 13

It worked on my local machine, but that's with Composer 2.1.12. After upgrading to Composer 2.2.1 vendor/bin/dep fails with the above error.

So Deployer is not compatible with Composer 2.2. I've downgraded Composer in the workflows to 2.1 and it works fine.

[danshumaker]

Cross reference

[antonmedv]

I also found possible bug.

[Seldaek]

The root cause of the problem seems to be a06f5a0#diff-e951b5e8891773756ee4536d362570e77c7f1ed92fc5749dc47f61e9ba908f7dR41-R51 (or

deployer/bin/dep

Lines 45 to 62 in cfcb963

	if (!isset($localBinaryOverrideFound)) {
	$binaries = [
	dirname($deployFile) . '/vendor/bin/dep',
	dirname($deployFile) . '/deployer.phar',
	getcwd() . '/vendor/bin/dep',
	getcwd() . '/deployer.phar',
	];
	foreach ($binaries as $binary) {
	if (file_exists($binary)) {
	if (realpath($binary) === realpath(__FILE__)) {
	break; // Already required this binary
	}
	$localBinaryOverrideFound = true; // Only do it once.
	require $binary;
	exit;
	}
	}
	}

in current master branch)

This was always broken but you did not notice it before because sometimes vendor/bin/dep was a symlink to vendor/deployer/deployer/bin/dep, but in some env it would not have been a symlink and would break the way it is breaking now. As of Composer 2.2 it is never a symlink anymore.

The other way this is broken is that bin-dir can be configured in composer.json, so inspecting only vendor/bin/dep makes no sense IMO.

It would probably make more sense to check for the following paths:

        dirname($deployFile) . '/vendor/deployer/deployer/bin/dep',
        dirname($deployFile) . '/deployer.phar',
        getcwd() . '/vendor/deployer/deployer/bin/dep',
        getcwd() . '/deployer.phar',

Although vendor-dir can also be configured, it is very rarely done so perhaps it's good enough. bin-dir however I have seen being changed to bin/ instead of vendor/bin/ quite often.

[antonmedv]

I’m going to remove this code. It already caused a lot of trouble. Thanks @Seldaek for looking into this.

[sprankhub]

@antonmedv any idea when you are able to have a look at that? It currently blocks our deployment. @Seldaek suggested running vendor/deployer/dist/dep as a workaround. However, this does not work for us as well. It fails with the same error.

[Seldaek]

If you're blocked, composer self-update 2.1.14 will get you back to a composer version which works, until this gets fixed, then please don't forget to update Composer to latest again :)

[gothick]

If you're blocked, composer self-update 2.1.14 will get you back to a composer version which works, until this gets fixed, then please don't forget to update Composer to latest again :)

Incidentally, you seem to only need this when installing deployer—if you go back to composer 2.1.14, then require deployer, then immediately composer self-update --rollback, everything seems to carry on working with the latest version. I presume that composer just leaves existing scripts in /vendor/bin and doesn't try to proxy them?

[antonmedv]

I deleted the problem code from bin/dep (which was requiring itself). Will release a new RC this week.