ddev: ddev command issues in composer post-create-project-cmd with ddev 1.18.2 (read /dev/stderr: bad file descriptor)

DDEV version v1.18.2
architecture arm64
db drud/ddev-dbserver-mariadb-10.3:v1.18.2 dba phpmyadmin:5
ddev-ssh-agent drud/ddev-ssh-agent:v1.18.0
docker 20.10.12
docker-compose v2.2.2
mutagen 0.12.0
os darwin
router drud/ddev-router:v1.18.2
web drud/ddev-webserver:v1.18.2

Describe the bug Some context: We have PHP starter kits for CMS and frameworks containing framework settings, decencies, CI and ddev setups. In order to install those, we leverage composer create-project command which trigger post-create-project-cmd scripts. As we need a specific ddev configuration provided by the starter kits themself, we can’t use the custom ddev composer create command. Commands will first launch ddev with ddev start, then run other ddev commands to initiate the project and the framework, ddev yarn install for example. That was working like a charm with ddev 1.18.1 and lower, but no longer.

The bug (regression): As of ddev 1.18.2 and higher, no matter which platform you’re on (linux, Mac Intel or Mac M1), starting ddev will work but the remaining commands will fail with a read /dev/stderr: bad file descriptor error.

To Reproduce Using ddev 1.18.2, install a PHP project using composer create-project containing a composer configuration like:

...
"type": "project",
...
"scripts": {
    "post-create-project-cmd": [
        "ddev start",
        "ddev yarn install",
...

Running that on ddev 1.18.2 will result in a read /dev/stderr: bad file descriptor on the ddev yarn install command. (This has been tested on Linux, Mac Intel and Mac M1 arch).

Expected behavior ddev commands should run without error.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 32 (17 by maintainers)

Most upvoted comments

Well that’s nice! ddev v1.19.1 uses docker-compose v2.3.3, and they’ve been making some progress on stdout/stderr, even though there’s still a ways to go.

rfay on Mar 23, 2022

The fact that you are using docker-compose v1 with your setup would definitely affect this before ddev v1.18.2. I’m sure you know that you can change that in the docker desktop settings and also switch with docker-compose enable-v2, but that’s irrelevant with current ddev, which uses v2.2.2 by default.
You can change the version that ddev uses with ddev config global --required-docker-compose-version
You can also use ddev config global --use-docker-compose-from-path, which right now for you would be the easiest way to demonstrate your situation.
using install_ddev.sh is the easiest way to switch ddev versions these days. Homebrew used to have a switch option but they removed it for some reason.

rfay on Feb 18, 2022

Ah, I guess I thought it was a generic craft starter for anybody, I guess it’s an in-house starter.

If you have an inter-device move failure, that’s odd. But in recent alphas, it doesn’t move from /tmp, it has gone back to using a subdirectory and copying instead of moving.

I also want to make sure you saw

https://github.com/drud/ddev/issues/3594

And you may want to add to the suggestions there.

Overall, I think we’ll be able to get your ddev composer create going better, but the bottom line is that you’re doing too much right now in a monolithic structure that isn’t working out in a docker context, and I don’t think I’m going to be able to help with it as it is.

I do recommend the approach of using --no-install on the initial setup, and then doing the ddev composer install afterward.

But I’m going to go ahead and close this, as it seems to be something I’m not going to be able to directly help with. Happy to continue the conversation here or elsewhere, and happy to help architect other approaches.

rfay on Feb 14, 2022

@rfay I’ve send you an invitation and an email with instructions to access a project on our Gitlab repository. Let me know if you have and trouble with it and thanks again.

juban on Feb 9, 2022