How to get a Composer global install in place for the user created in web image?

[lpeabody]

I want to run composer global require ... and have the package binaries that get brought down available to the user of the container. So, after a ddev start I should be able to run ddev exec custom-composer-binary and the binary present in /home/username/.composer/vendor/bin should be available in username's PATH.

I tried adding:

ARG BASE_IMAGE
FROM $BASE_IMAGE

USER $username

RUN composer global require balbuf/composer-git-merge-driver --no-interaction

USER root

Only to find that DDEV adds it in the compiled Dockerfile before its standard user creation command. This is the result in .webimageBuild/Dockerfile:

ARG BASE_IMAGE
FROM $BASE_IMAGE

USER $username

RUN composer global require balbuf/composer-git-merge-driver --no-interaction

USER root

ARG username
ARG uid
ARG gid
RUN (groupadd --gid $gid "$username" || groupadd "$username" || true) && (useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' --uid $uid "$username" || useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' "$username" || useradd  -l -m -s "/bin/bash" --gid "$gid" --comment '' "$username")

RUN export XDEBUG_MODE=off && ( composer self-update --2 || composer self-update --2 )

Is there a way to prevent DDEV from appending that snippet altogether? And then I could just add the snippet it wants, just in the proper order. This is really frustrating. Any help is appreciated.

[rfay]

Please take a look at https://stackoverflow.com/questions/61870801/add-global-phpcs-and-drupal-coder-to-ddev-in-custom-dockerfile and see if it answers your question and solves the problem.

[lpeabody]

It's the difference between images and containers that's bothering you

I've told you I've been working with Docker and image building for years now, please don't patronize me. To do what I want to do, all DDEV needs to do is allow this result:

ARG BASE_IMAGE
FROM $BASE_IMAGE

ARG username
ARG uid
ARG gid
RUN (groupadd --gid $gid "$username" || groupadd "$username" || true) && (useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' --uid $uid "$username" || useradd  -l -m -s "/bin/bash" --gid "$username" --comment '' "$username" || useradd  -l -m -s "/bin/bash" --gid "$gid" --comment '' "$username")

RUN export XDEBUG_MODE=off && ( composer self-update --2 || composer self-update --2 )

USER $username

RUN composer global require balbuf/composer-git-merge-driver --no-interaction

USER root

That adds the user, and now I can modify the user's home environment as I see fit. Effectively, DDEV needs not append its user creation snippet to the Dockerfile that builds the image, it should prepend it.

[rfay]

I think you might have more fun discussing this with a bigger audience, in discord, where the community meets, https://discord.gg/hCZFfAMc5k - you could get a variety of views there.

If you want to customize the individual user, the easiest way is usually with the homeadditions feature, https://ddev.readthedocs.io/en/latest/users/extend/in-container-configuration/

ddev goes to great lengths to provide a user environment, including username and uid that match the host.

I'm afraid I've lost track of what you actually want, and am not understanding. I thought this was about composer install --global, and that was explained immediately. Probably discord is a good place to start. But you've gotten a pile of immediate, free, direct support and you seem to just respond with irritation. Be nicer in discord please.

[lpeabody]

Apologies for coming off as irritable and short-tempered. You've been very helpful and I appreciate anyone who puts in as much time as you have to OSS for free.

ddev goes to great lengths to provide a user environment, including username and uid that match the host.

And I actually think this is a really cool feature of DDEV and it's a technique I may reuse in other projects down the road.

I'm afraid I've lost track of what you actually want

Ultimately what I wanted to do was drop a global Composer binary in the user's ~/.composer/vendor/bin directory, but that couldn't be done unless I was running the composer require ... command as that user (and then also add that path to that user's PATH value). You helped inspire a solution to that by sharing that SO article, thank you again for that.

I then just pointed out what I would typically do with a Dockerfile to get this setup the way I wanted, and I guess sort of implying that this would be a useful feature of DDEV to me. You didn't lose track of anything :) I guess a more generalized question that would have answered my original question could have been phrased as "How to modify the image after DDEV has added its user creation steps?"

I think you might have more fun discussing this with a bigger audience

I'm certain folks would either point me at some examples or maybe point me at some documentation I haven't read yet, to help relieve my quandary of how to manipulate the built image in the way I've illustrated above. Or just point out a different way to frame my thinking when it comes to customizing DDEV container environments (i.e. there seems to be more emphasis on manipulating a container after its built, rather than just building one image with all project dependencies in it).

Thanks for pointing out Discord as a resource, and thank you for your time and assistance and contributions to OSS.

[rfay]

Why the requirement to put the binary in the user's ~/.composer directory?

BTW, you can do that by just putting it into <project>.ddev/homeadditions/.composer/vendor/bin, but it's not a very pretty solution.

[lpeabody]

Why the requirement to put the binary in the user's ~/.composer directory?

I guess because that's where I'm accustomed to putting global packages since they're typically installed on a per-user basis.

BTW, you can do that by just putting it into .ddev/homeadditions/.composer/vendor/bin, but it's not a very pretty solution.

Agreed! It would work, but, its definitely one of those things that I would normally just bake into an image. I'll continue using DDEV for a while and as I learn more hopefully these questions I have will get answered. I can't be the first person who wanted to do something like this, so, there must be established ways that folks have gone about making similar changes, I just haven't seen all of the use cases/examples pertinent documentation yet. If I continue to run into this situation and find that I really want the feature still, I'll open an issue and PR documenting the use cases and implementation.

Thanks for your time @rfay.