Edit php configuration wp-env

[maru3l]

What problem does this address?

I need to increase the max_upload_filesize and I can't find how to edit the php.ini. I've tried to edit the ~/.wp-env/{HASH_OF_MY_PROJECT}/Dockerfile by adding RUN echo 'upload_max_filesize="512M"' >> /usr/local/etc/php/php.ini but when I do a wp-env start --upgrade, it replace the entire Dockerfile.

What is your proposed solution?

I think the best solution should be to add php configuration params in the .wp-env.json. Something like :

{
    "phpConfig": {
        "post_max_size": "512M",
        "upload_max_filesize": "512M",
        "memory_limit": "512M",
    }
}

An other idea should be to Specified a customer Dockerfile to use. The only downside of this one is auto configuration like wordpress version, core version or xDebug configuration won't work.

[ockham]

This unfortunately highlights an issue with a high-level wrapper such as wp-env: It provides an abstraction layer over a system that consists of various parts, each of which can be configured individually (thing Docker, WordPress, MySQL, etc). As time progresses, we discover that we actually need to configure more and more of those parts, and thus need to expose/replicate their configs at wp-env level. This increases the overall maintenance burden; furthermore, it requires people that are already familiar with configuring these individual parts to look up how these are mapped by wp-env (rather than relying on the individual parts' online docs and Q&As).

This is a problem that is (partly) solved by Docker and docker-compose, since these tools are facing similar issues. It'd be interesting if rather than wrapping these tools in an extra layer (wp-env), that, among other things, dynamically generates a docker-compose.yml, we can leverage existing techniques provided by Docker/docker-compose (such as providing a static docker-compose.overrride.yml).

One hypothesis here could be: Our use case here isn't that special; there might be precedent out there where people need to configure their docker-compose based systems, and have found ways to inject config options and settings, rather than adding and maintaining a whole new abstraction layer.

[maru3l]

I think the use case of wp-env is to offer an easy way to build a docker environment for someone who doesn't know how to use docker or for someone you want a fast and easy way to get a development environment.

Personally, I am a devOps who are using it for my team who don't know how to use docker. The learning curve is too much for them. It's easier for them to look at the documentation of wp-env and edit the configuration file then start to learn how to configure docker-compose.yml and dockerfile.

That's how I see wp-env, an abstraction of docker for someone who doesn't know how to use it or just want to scaffold without pain a Wordpress development environment.

I think the way to go with this issue is to offer the possibility to add configuration in the .wp-env.json. This is the easiest and fastest way for someone who doesn't know how docker work to add custom configuration. If someone went more flexibility on his installation, he should create his own docker setup.

Another interesting command could be a wp-env scaffold --xdebug who creates all the docker files needed at the root project. After the user would be able to edit the file the way he want and run wp-env start, wp-env stop or wp-env clean. The only command he wouldn't be able to run is the one who updates the docker files because we don't want to erase the modification he made.

[ribaricplusplus]

Docker containers are meant to be immutable: The environment is declaratively defined in a Dockerfile, thus it's easily reproducible.

As far as I know, the Dockerfile that defines wp-env WordPress containers cannot be modified by wp-env users. They have to modify files (e.g. php.ini) inside of a running container which breaks the point of Docker being immutable and reproducible.

So either we let users modify Dockerfile and docker-compose.yml, or we add the proposed phpConfig option. I think adding phpConfig is reasonable for now. Changing PHP directives is a common use case and it's not a complex thing to do. If configuration demands for other parts of wp-env increase in the future, we can add direct access to Dockerfile and docker-compose.yml (which will make things harder for users but it will address @ockham's point).

[ribaricplusplus]

If we decide to go the phpConfig route, I've created a PR with the implementation because I need this feature.

[ribaricplusplus]

If you need the phpConfig feature right now, you can use my fork of wp-env until the change is merged into the official version https://github.com/ribaricplusplus/wp-env

[hjvedvik]

This worked for me:

php.ini

post_max_size = 512M
upload_max_filesize = 512M
memory_limit = 512M

.wp-env.json

{
  "mappings": {
    "php.ini": "./php.ini"
  }
}

[noahtallen]

I think we should move forward with the phpConfig approach and set it up so that it could be different based on different environments in the future. Mapping php.ini is also a cool workaround, but I think we should support it in wp-env for the following reasons:

• Ideally, wp-env.json is all you need for the environment to work.
• If we just map the files, that doesn't leave a path towards supporting different options for different environment, or being able to override options with .wp-env.override.json.
• Adding it to wp-env.json lets the configuration be available for "power users" without increasing complexity for any other users of wp-env.

[ockham]

I think the use case of wp-env is to offer an easy way to build a docker environment for someone who doesn't know how to use docker or for someone you want a fast and easy way to get a development environment.

I agree that's the premise that wp-env is built on. I still think it's a fallacy 😬 I'll elaborate below...

Personally, I am a devOps who are using it for my team who don't know how to use docker. The learning curve is too much for them. It's easier for them to look at the documentation of wp-env and edit the configuration file then start to learn how to configure docker-compose.yml and dockerfile.

My point is, they wouldn't. I agree that we want to give people simple recipes to follow, which don't require them to learn about the underlying tooling. But I think that can be done just as fine if we remove the wp-env abstraction layer, and expose them directly to docker-compose.

We'd basically just change a few lines in what is now the packages/env/README. E.g.

diff --git a/packages/env/README.md b/packages/env/README.md
index 2b66a6da75..549ae2f903 100644
--- a/packages/env/README.md
+++ b/packages/env/README.md
@@ -76,7 +76,7 @@ $ cd ~/gutenberg
 Then, start the local environment:
 
 ```sh
-$ wp-env start
+$ docker-compose up
 ```
 
Finally, navigate to http://localhost:8888 in your web browser to see WordPress running with the local WordPress plugin or theme running and activated. Default login credentials are username: `admin` password: `password`.

That's how I see wp-env, an abstraction of docker for someone who doesn't know how to use it or just want to scaffold without pain a Wordpress development environment.

Most of that could be contained in a docker-compose.yml -- there wouldn't be any need to have a script generate that on the fly. There's probably still some value in having some sort of WordPress dependency management -- having some sort of config file where we can define which themes and plugins to use, specify their versions (and Core's), and which sources to use (e.g. the WP.org plugin/themes repos, or a GH repo). A bit similar to npm or composer. wp-env does a good job at that, but IMO, it blends this functionality too much with all the virtualization stuff (i.e. Docker wrapper).

And BTW, the abstraction is kind of leaking already: The packages/env/README.md points to some docker commands already -- e.g. prominently under the "Check that wp-env is running" headline. That means that even now, we can't shield our users fully from some exposure to Docker. I think that's symptomatic of the problem.

I think the way to go with this issue is to offer the possibility to add configuration in the .wp-env.json. This is the easiest and fastest way for someone who doesn't know how docker work to add custom configuration.

I agree that we'd want to retain functionality that provides e.g. a set of themes and plugins OOTB. But if we base that on a WP dependency manager, there might be a number of options that don't involve dynamically generating a docker-compose.yml -- we could e.g. run that as a WP CLI command from within the virtualized WP instance, or use a docker-compose override file.

If someone went more flexibility on his installation, he should create his own docker setup.

This sheds light on an important problem: People can't simply "graduate" from wp-env, it's either all or nothing. If we stripped away the wrappers and used Docker/docker-compose more directly, people would be gently introduced to it -- first by just copy-pasting commands like docker-compose up -- but later they'd be able to e.g. look for information online by searching for existing Docker documentation or questions; and having been somewhat exposed to its config files, they'd know what to edit (or add and override for). With wp-env, all this is hidden under the wraps -- there isn't really a path forward for users that need a bit more flexibility: Instead, they basically have to start at square one, learn about Docker, and maybe write their own docker-compose.yml from scratch.

Or -- and perhaps more realistically -- they will file an issue or PR, requesting for this feature to be added. Which is what we're seeing, and what I predict we'll continue to see. And we can't just say, oh, we won't implement this since we don't think there's enough demand for this feature, but you can do xyz in your docker-compose.override.yml -- which we could otherwise.

So we're currently in this constant state of playing catch-up with feature and extension requests for wp-env, where oftentimes all we need is to extend our abstraction layer by a bit of new syntax that feeds through e.g. to some option of the wordpress Docker container -- as is the case with the present issue. And that image actually has documentation for that (under "Configuring PHP directives"), so it'd be fairly easy for people to find.

Meanwhile, the whole thing is kind of a pain to maintain already -- which I attribute mostly to its many layers of indirection. See e.g. this comment for a 🐰 🕳️ I went down earlier (and which seems to be making some PHP unit tests unreliable).

Another interesting command could be a wp-env scaffold --xdebug who creates all the docker files needed at the root project. After the user would be able to edit the file the way he want and run wp-env start, wp-env stop or wp-env clean. The only command he wouldn't be able to run is the one who updates the docker files because we don't want to erase the modification he made.

🤷‍♂️ Anything that removes some of the current indirection is fine in my book. This could be a start; though I think the bigger question is how to properly isolate the concern of dependency management, and integrate that cleanly with Docker/docker-compose. If we solve that problem, we might not need to scaffold or generate the docker-compose.yml file at all but could maybe just ship one as part of the repo.

[noahtallen]

Thank you for raising this conversation Bernie; I definitely think it's valuable to talk about. I agree with a lot of your pain points. It is a pain to maintain. It is tricky to know what features to add.

However, I remember back to why this was introduced in the first place, and the reality was that if you wanted to use Docker, you either had to roll your own docker-compose, which no one wanted to do because it can be tricky to get right individually, or try to access the docker-compose file used by a different plugin. (For example, lots of people were trying to hack their dev environment on top of the Gutenberg or Jetpack environments)

I think wp-env also wraps up other parts of interacting with Docker which are not nice:

• wp-env destroy. If that command wasn't available, you'd be searching how to remove the containers and networks. It's a really nice, fast, memorable abstraction over something that's otherwise more complicated than it needs to be.
• wp-env logs. This command could be improved, but I remember having to constantly re-learn how to access logs in the container.
• wp-env start. Everything related to installation.
• Basically anything which requires interaction with docker rather than docker-compose.

I think I might agree with you more if wp-env was just abstracting docker-compose. But it's also abstracting Docker, parts wp-cli, parts of phpunit, dependency management, etc. It's doing a lot of heavy lifting that would otherwise require you to learn a lot of tools just to get going. Plus, there's something pretty awesome about just cding to a plugin directory, running wp-env start with no config, and being ready to go (including plugin activation).

Additionally, the big problem docker-compose by itself is that you typically have to get a lot of work to have everything running correctly. Every individual team or person has to tinker with the file to get things working. By default, it's likely not going to support things you might need.

In other words, I think wp-env is trying (sometimes successfully, sometimes unsuccessfully) to make a docker-compose/docker set up that installs everything you need so that you don't have to tweak it. You don't have to do bug fixes so long as they are fixed in wp-env and updates are published frequently. (This is one area where the project needs improvement. It needs more devs and independent npm updates.)

In even plainer words, I think the best DX is getting an environment which has everything you need out of the box, without you having to work for it. I think there are two parts of that:

1. Firstly for project maintainers to not have to create and maintain their own environment.
2. Secondly, for any consumers or developers of that project to get something which works out of the box and has the features they need to get work done. (Like showing logs, destroying the environment, running wp-cli commands, etc.)

I don't think that item 1 is solved with docker-compose. I think it is partially solved by wp-env. I think there is so much potential for wp-env to do more and better in this area.

I think parts of item 2 are solved by docker-compose. You get a similar interface as wp-env for several commands. I think wp-env is still a slight bit nicer to use for most things, but it's not as clear of a difference as the first item.

All that said, I want to be clear about my own limitations. I'm maintaining this project because it was painful as a plugin maintainer to set up a dev environment, and because it was painful as a plugin developer to use existing dev environments. I'm new to both WordPress and Docker (as of a couple years ago), so there's lots of stuff I don't have an advanced understanding of. So are there better solutions?

• Could we write and maintain our own Dockerfile which supports everything like Xdebug and phpunit out of the box?
• Is there a way for us to maintain a docker-compose file that others can extend?
• Could wp-env be changed to work with existing docker-compose files, to add a consistent API across any docker/WordPress dev instance?

Finally, I'm excited to continue this conversation. We definitely need to determine the motivating goals for this project and then stick to them going forward.

First, check that wp-env is running. One way to do this is to have Docker print a table with the currently running containers:

IMO, we could even remove that line. wp-env tends to fail pretty spectacularly if things go wrong.

See e.g. this comment for a 🐰 🕳️ I went down earlier (and which seems to be making some PHP unit tests unreliable).

In my opinion, this is more to do with how we have to use wp-phpunit to make the WP test library available. I think we could fix that problem, I'm not sure it's completely related to wp-env. It might be more because I didn't/don't know much about phpunit when I set it up. I made an issue and PR a while ago for automagically installing the test library from WP which matches the version of WordPress you have installed. That would reduce a lot of the indirection required to get phpunit up and running.

[ockham]

Thanks @noahtallen for your thoughtful reply! I truly appreciate the work and thought you've put into wp-env. I'm also glad that we're having this conversation about potential improvements for wp-env to make it more easily maintainable while not compromising on Developer Experience 😄

However, I remember back to why this was introduced in the first place, and the reality was that if you wanted to use Docker, you either had to roll your own docker-compose, which no one wanted to do because it can be tricky to get right individually, or try to access the docker-compose file used by a different plugin. (For example, lots of people were trying to hack their dev environment on top of the Gutenberg or Jetpack environments)

Thanks for bringing that up, and great point 👍 I've long thought that it'd be great to have a standardized developer environment that can be used by a number of different projects. It's great that wp-env has seen some adoption; I wish that there was already a bit more consistency across the dev envs e.g. for Gutenberg, https://github.com/WordPress/wordpress-develop/, and Jetpack.

I think I might agree with you more if wp-env was just abstracting docker-compose. But it's also abstracting Docker, parts wp-cli, parts of phpunit, dependency management, etc.

This is a double-edged sword, however: IMO, wp-env is confronted with the sort of problems that anything that seeks to provide an abstraction layer on top of a rather heterogenous set of tools will face: Defining a config file format (that can grow with time), translating config settings into tool options, etc. These present a non-negligible maintenance overhead; but even more problematic, they can distract from more fundamental questions -- mostly around separation of concerns.

It's doing a lot of heavy lifting that would otherwise require you to learn a lot of tools just to get going. Plus, there's something pretty awesome about just cding to a plugin directory, running wp-env start with no config, and being ready to go (including plugin activation).

Yes, absolutely. But to be clear, this is a goal I wouldn't compromise on for whatever alternative solution we'd be able to come up with.

Additionally, the big problem docker-compose by itself is that you typically have to get a lot of work to have everything running correctly. Every individual team or person has to tinker with the file to get things working. By default, it's likely not going to support things you might need.

This is a statement that IMO deserves closer scrutiny 😬 What are the things that people have to tinker with? After all, docker-compose purports to be a tool that people use for similar purposes, and offers customization through mechanisms like override files, rather than presenting itself as something that's necessarily difficult to work with or to require writing those files programatically. Maybe we just haven't found all the built-in bells and whistles yet 😉

To make this more concrete, I think we should have a look at the docker-compose.yml that's generated from a given .wp-env.json (e.g. the one that's shipped with Gutenberg), and review which parts of it require what kind of information, and what level of dynamism. We could do that quite literally -- I'm thinking to file a PR that would add my current ~/.wp-env/.../docker-compose.yml that we can then analyze line-by-line. (Once we're done with that, we could move on to other config files, such as the Dockerfile.)

In other words, I think wp-env is trying (sometimes successfully, sometimes unsuccessfully) to make a docker-compose/docker set up that installs everything you need so that you don't have to tweak it. You don't have to do bug fixes so long as they are fixed in wp-env and updates are published frequently. (This is one area where the project needs improvement. It needs more devs and independent npm updates.)

I'm afraid that this is where I believe that theory and practice disagree: Of course wp-env would benefit from more devs and resources, but barring that, we should make the entry barrier for new devs lower. (And I selfishly include myself there: Having worked with wp-env a bit, I believe that I've identified that all these extra layers -- e.g. build-docker-compose-config.js -- make it harder to reason about the information flow, and thus harder to contributing to it.) I'm aiming for a virtuous cycle: Have few contributors; have them prioritize simplification of the code and architecture; attract more contributors, since it's becoming easier for them to add features or fix bugs.

In even plainer words, I think the best DX is getting an environment which has everything you need out of the box, without you having to work for it.

Yes -- I hope I've made it clear that I share this goal! Where I do believe I differ is the "next step" for people that want that, but want to make some minor tweaks on top of that setup: I want them to be able to "graduate" from their initial OOTB setup; requiring a minor tweak should map to changing only few lines, if it's only a few lines of configuration that the underlying tool needs changed. In order to contribute a fix like that to wp-env, they'd currently have to peel through a number of files, typically build-docker-compose-config.js, wordpress.js, etc -- on top of finding out what to change in the underlying tool's config! I do believe that this tradeoff plays a role why we aren't seeing a ton of contributions to wp-env, and why a lot of folks end up filing feature requests instead, which in turn increase, rather than decrease, the potential workload for wp-env maintainers -- i.e. you, for the most part 😬

All that said, I want to be clear about my own limitations. I'm maintaining this project because it was painful as a plugin maintainer to set up a dev environment, and because it was painful as a plugin developer to use existing dev environments. I'm new to both WordPress and Docker (as of a couple years ago), so there's lots of stuff I don't have an advanced understanding of. So are there better solutions?

• Could we write and maintain our own Dockerfile which supports everything like Xdebug and phpunit out of the box?
• Is there a way for us to maintain a docker-compose file that others can extend?
• Could wp-env be changed to work with existing docker-compose files, to add a consistent API across any docker/WordPress dev instance?

I think that those are great questions to ask! Let's start exploring; I'll file a PR as mentioned above to serve as a starting point 👍

Finally, I'm excited to continue this conversation. We definitely need to determine the motivating goals for this project and then stick to them going forward.

👍 👍 👍

See e.g. this comment for a 🐰 🕳️ I went down earlier (and which seems to be making some PHP unit tests unreliable).

In my opinion, this is more to do with how we have to use wp-phpunit to make the WP test library available. I think we could fix that problem, I'm not sure it's completely related to wp-env. It might be more because I didn't/don't know much about phpunit when I set it up. I made an issue and PR a while ago for automagically installing the test library from WP which matches the version of WordPress you have installed. That would reduce a lot of the indirection required to get phpunit up and running.

Sounds good, I'll have a look into that issue and PR!

[noahtallen]

Fantastic reply Bernie, thanks! It sounds like we're on the same page about the desired DX -- so the question is what to do to get there. Thanks for opening that PR, I'll be happy to continue the conversation there.

I want them to be able to "graduate" from their initial OOTB setup; requiring a minor tweak should map to changing only few lines, if it's only a few lines of configuration that the underlying tool needs changed. In order to contribute a fix like that to wp-env, they'd currently have to peel through a number of files

Digging into this scenario a bit, I'm apprehensive about the docker-compose approach because it feels like it's not upgrade-able. Then, any fixes or improvements become the burden of individual plugin maintainers, rather than just updating the environment tool.

[ockham]

Digging into this scenario a bit, I'm apprehensive about the docker-compose approach because it feels like it's not upgrade-able. Then, any fixes or improvements become the burden of individual plugin maintainers, rather than just updating the environment tool.

Would it? 🤔 We'd probably still be shipping a docker-compose.yml in wp-env, and a docker-compose.override.yml at the root level (of Gutenberg, or any plugins/themes that use wp-env), so those would be amenable for centralized fixes. But maybe I'm not seeing clearly; can you give a concrete example?

[noahtallen]

I think I might misunderstand your suggestion! Let me see if I get this right:

Your thought is to have wp-env provide a default docker-compose.yml file, which is "hidden". (Like we currently do, though we won't generate it from the config anymore.)

The way users replicate ".wp-env.json" is by creating the docker-compose.override.yml file in their project, right?

In that case, I'm getting much more on board with the idea. I originally thought you meant that each project would have the entire docker-compose in VCS.

I do think it would simplify things a great deal. Though, how do we replicate .wp-env.override.json now? Is there a second level of override possible with docker-compose?

[pbking]

Interesting ideas and discussion. I really like the idea of having the docker configuration closer to me and starting out might have been a little easier for my brain to understand. Then I knew little of WordPress and only enough about Docker to tinker. . .wp-env.*.json is comfortable to me now, though and I would really miss the feature of unzipping/unpacking resources, something I don't know how you could replicate without that kind of configuration.

[ockham]

I think I might misunderstand your suggestion! Let me see if I get this right:

Your thought is to have wp-env provide a default docker-compose.yml file, which is "hidden". (Like we currently do, though we won't generate it from the config anymore.)

The way users replicate ".wp-env.json" is by creating the docker-compose.override.yml file in their project, right?

Yep, that's pretty much the idea! 😄

In that case, I'm getting much more on board with the idea. I originally thought you meant that each project would have the entire docker-compose in VCS.

No, I think it makes sense to provide a 'packaged' baseline config for WP development -- this would continue to be wp-env's role.

I do think it would simplify things a great deal. Though, how do we replicate .wp-env.override.json now? Is there a second level of override possible with docker-compose?

Yeah, that seems to be possible; although I'm not totally sure how ergonomic it would be:

To use multiple override files, or an override file with a different name, you can use the -f option to specify the list of files. Compose merges files in the order they’re specified on the command line. See the docker-compose command reference for more information about using -f.

There's another (albeit legacy) way to modularize docker-compose configs, but I'm not sure if that's applicable to our use case, and if we should use it at all -- given that it's legacy.

But it seems like there are enough options that we'll be able to figure something out 😄

[gaambo]

This worked for me:

php.ini

post_max_size = 512M
upload_max_filesize = 512M
memory_limit = 512M

.wp-env.json

{
  "mappings": {
    "php.ini": "./php.ini"
  }
}

@hjvedvik
I couldn't get this to work. The php.ini will be mapped to /var/www/html/php.ini but it's values don't get applied and checking php --ini confirms, that it's not getting loaded. I also don't think that's a standard apache, loading additional .ini files in the public folder has to be enabled/configured.

[eliot-akira]

This took me a while to figure out, so I'm leaving a comment with a solution that worked for me.

.wp-env.json

{
  "mappings": {
    ".htaccess": "./.htaccess"
  }
}

.htaccess

php_value post_max_size 512M
php_value upload_max_filesize 512M
php_value memory_limit 512M

I got the idea from the unmerged pull request #32363.

---

There's another issue #29430 regarding the same question as this one #28703, about how to increase the default upload size limit.

Both of these have been unresolved for two years, even though there's a pull request that addresses them. I understand there's a discussion about the ideal design of wp-env and its configurability, whether to provide an option phpConfig or not - but it seems this is an example of:

Perfect is the enemy of good is an aphorism which means insistence on perfection often prevents implementation of good improvements.

[ribaricplusplus]

I've made a few contributions to wp-env and created like 3 forks in order to suit my purposes. Honestly, in my opinion, you should just not use wp-env at all in its current state. If you do, you're about to have lots of fun as soon as you need more advanced configuration. I rather use LocalWP with its Blueprints and custom wp cli scripts if any site initalization is needed.

Just my recommendation for anyone who comes across this comment. People may disagree.

[noahtallen]

You both definitely make good points -- wp-env so far just doesn't have enough maintainers to really make it a very advanced tool. I still think that it's great for simple local environments, but I'm happy to admit there are many tools that provide more advanced functionality! (And happy to admit there are plenty of shortcomings to wp-env.)

Here's where I think this stands:

• increase default values for upload size (possibly doable via our Dockerfiles?)
• allow php.ini to be used by apache by default
• document using mappings for .htaccess or php.ini

This makes php config easily editable and hopefully reduces how much it's needed in the first place

[eliot-akira]

Going back to the top of this issue report, I actually think it was a sensible decision to not add the option phpConfig. The reasoning explained in the first reply makes sense.

..[wp-env] provides an abstraction layer over a system that consists of various parts, each of which can be configured individually (think Docker, WordPress, MySQL, etc). As time progresses, we discover that we actually need to configure more and more of those parts, and thus need to expose/replicate their configs at wp-env level.

This increases the overall maintenance burden; furthermore, it requires people that are already familiar with configuring these individual parts to look up how these are mapped by wp-env (rather than relying on the individual parts' online docs and Q&As).

I can see the value in keeping wp-env simple and "limited", by not catering to every feature request. In fact, that's what I love about it compared to larger, more advanced tools like LocalWP (which is also proprietary and not open source).

And it turned out that there is a solution using an existing feature, of mapping php.ini (which didn't work for me) or .htaccess (which did work - I didn't know Apache had a way to override PHP settings from this file).

So it seems that providing such "escape hatches" (and documenting them) is a good way to support advanced use cases, for people who need to configure the underlying parts. That would give a lot of flexibility, while still keeping things simple for wp-env itself.

I also like the idea that was getting developed through discussion, some way to modularize and customize the generated docker-compose config file. That sounds like a more long-term vision. It reminds me of how the create-react-app tool has an "eject" command: a one-way operation that copies the generated config files into the project, so the user can customize them further without relying on what the tool provides.