Provide an initialization command for a simple 1:1 production copy

[joshsedl]

Still one may need an environment that reflects the prod environment 1:1, but while that sounds easy, there are very difficult points which can't be automated that simple in all aspects.

Things like:

Online settings.php (with real DB credentials!) which can't be used local and may never be changed. It may contain important secrets for the functionality. But if we add a local.settings.php file, this would mean, we're also changing the project!
Different Drupal CMS configurations, folder structure, vhost, ... can't be simply assumed like in our environment. This may include folders which are outside of the regular structures (private files)
Proxying files and such things can't be done, as we'd need a custom module and that would also change the installation!
...
so, it's NOT trivial!
We first need a clear plan and concept here, before changing the implementation in large parts!
Things should be clear and easy from the end-user perspective.

And we have to decide, what's worth it, based on regular usage! Things evolve fast... and time is the currency.

[joshsedl]

Originally taken from #121

[joshsedl]

Alternatively, we could also implement this functionality inside "drowl-init-from-existing"

[joshsedl]

Comment by @JPustkuchen in context of attaching VSCode Settings:

I think apart from ddev / docker / remote the correct way here is indeed to use the .vscode folder and/or .code-workspace file instead of other possible workarounds. That's also transparent!
See https://code.visualstudio.com/docs/editor/workspaces

For production copies I think this should not be used by default.

Idea: perhaps instead of having -dev and -prod with different receipts, we should have smaller flags like the "ddev xdebug on" which add or remove defined parts, like vscode configurations, dev modules etc.?

When setting up the project, these commands would then be called automatically, so they can also be split cleanly.

If you like the idea @joshsedl we should perhaps have a master plan issue for these prod / dev things and the idea could be elaborated there... I just wrote it down here, as I came up with this when thinking about vscode integration into production projects like Drupal dev modules etc... so it's not only Drupal specific.

[joshsedl]

@JPustkuchen I think, I don't quite understand your suggestion.

In my current understanding, I think that would be too much. If we add further dev modules, extensions, etc. this will get way to big, I don't see myself using a command like:
ddev drowl-init-from-existing --xdebug true --eslint true --phpstan true --intelephense true --xdebug-mode bla --enable-drupal-modules examples,admin_toolbar,abc --...

[joshsedl]

But I generally don't like the idea of this repository having a prod command.

I think a prod command would only make sense if we are keeping the local and remote copy in sync, without removing our dev tools locally.

[JPustkuchen]

@joshsedl I agree it's not that easy to understand, I think we'll have to go back a bit.

Problems to be solved:

• Allow to use this tool for dev environments and to run production copies (that should not be modified unintentionally)
• Allow to add certain features also for prod copies (e.g. vscode extensions & settings, Drupal dev modules) - in the end so or so they are always "commands"
• Whereever possible make these atomic/grouped by use-case
• Whereever possible make these removable
• Instead of having large receipts, split them by feature and in the main receipt, run the atomic commands

In practice all these points would be very helpful, because it can be used a lot more flexible and transparent than only with the startup-command (which also allows to enable / disable these by flags)

As an example, if we put the functionality into features that can be enabled or disabled like this (naming is just for example):

• ddev drowl-feature-add vscode-dev
• ddev drowl-feature-add drupal-dev
• ddev drowl-feature-add drupal-file-proxy
• ...

These command would then explain themselves and ask for confirmation, before execution. For example list which modules they will install and what they will change and if it's revertable.

You could setup the production copy where you can be sure nothing is modified by our tool automatically and so it can be re-uploaded to production.

With the features you now don't have to decide at the very beginning, if this is a dev or a prod copy. It's just for convenience, if you'd like to decide front-up. You can simply run ddev drowl-feature-add vscode and the vscode folder will be copied over!
Or you use sth. like
ddev drowl-init --no-vscode --no-drupal-dev
vs.
ddev drowl-init --vscode --drupal-dev
yet unclear which one to prefer via flags instead of drowl-feature-remove/add calls afterwards.

Now your prod copy couldn't be used for production upload anymore without manual cleanup...
But then

• ddev drowl-feature-remove vscode
• ddev drowl-feature-remove drupal-dev
• ...
  comes in and allows to revert the command by a defined undo mechanism. To take this to the top you maybe could even clean a dev environment in large parts.

This is just the expectation and I guess some receipts won't be revertable. But we can simply document this when running the -remove command and let the user know.

As a side-effect the ddev drowl-init(-from-existing) command will automatically be cleaned up, broken into pieces and more simple to understand, because the part where the Drupal dev modules are required and installed is now only a subcall on ddev drowl-feature-add drupal-dev (or similar) and can be reused!

I hope you got my point, otherwise let's just talk. The requirements from this come from daily practice so I'm sure this would make the devcontainer even more usable and flexible in real-world projects for us.