Support config.*.yaml in ddev config command

[h1nds1ght]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem?

Would it be possible to support the other config.*.yaml files when using ddev config?

I.e. when I want to disable settings management

ddev config --disable-settings-management

it changes the default config.yaml, but actually I want to change config.local.yaml.

Is there actually a way to do this via cli?

Describe your solution

t.b.d

Describe alternatives

No response

Additional context

No response

[rfay]

Hi @h1nds1ght there isn't a way for ddev config to target config.*.yaml at this time.

How would you add that capability if you were going to do it? What would it look like?

IMO since DDEV would not know what config.*.yaml you have in advance, it would lead to lots of errors, like creating new yaml files by accident, or putting the directive in the wrong yaml file, etc.

I confess that I have wanted this from time to time myself though.

[h1nds1ght]

Of course one should specify the file in advance. But I am not sure what would be the best way of doing this.

Currently I think there is 1 argument provider for ddev config:

ddev config [provider or 'global'] [flags]

Maybe we could use that, i.e.

ddev config custom:local [flags]

or

ddev config custom local [flags]

or add a new flag:

ddev config --use-custom-config=local [other-flags]

which would all assume a file located at ${DDEV_APPROOT}/.ddev/config.local.yaml. If its not there it will be created and if its there it will be modified.

[rfay]

A new flag that most people would never see or use would probably be OK with me. But I think you'd have to plan on doing a PR to make it happen.

[jameswilson]

Subscribe and +1.

I was mid-writing up effectively this same feature request when I went back and expanded my search and found this issue.

Here is what I wrote up, in case it sheds new light on this issue:

Is your feature request related to a problem?

Teams have ways to instruct their devs to create global configurations using CLI one-liners via ddev config global, but there is no concise way to document how to create local overrides with one-liners.

Describe your solution

Add explicit support for ddev config local to edit config.local.yaml.

Consider expanding the provider to support any string so that other addons that add their own config.*.yaml files can be modified via ddev config one-liners with flags.

Describe alternatives

In theory, this feature could be implemented as a new flag to ddev config, such as --local-override, but it seemed more consistent to support this with the existing "provider" functionality: ddev config [provider or 'local' or 'global'].

Additional context

This issue brings to light that ddev config supports providers other than 'global', but doesn't really explain what provider means in this context. Is it the same meaning as .ddev/providers/ ? If not, maybe it should be changed to not overload that word, in addition to being a little more clearly documented in help. (Could be a follow-up).

❯ ddev help config
Create or modify a DDEV project configuration in the current directory

Usage:
  ddev config [provider or 'global'] [flags]

[jameswilson]

I confess that I have wanted this from time to time myself though.

Same. For me, this issue came to light this most recent time because I want to be able to document concisely how to use different Drupal versions or PHP versions when maintaining several instances of a Drupal module, using Ddev Drupal Contrib:

git clone git@git.drupal.org:project/my_module.gi
cd my_module
ddev config --project-type=drupal --project-name=my-module --docroot=web --php-version=8.3
ddev get ddev/ddev-drupal-contrib
ddev config local --web-environment-add=DRUPAL_CORE=^9 --project-name=my-module-9

[h1nds1ght]

This issue brings to light that ddev config supports providers other than 'global', but doesn't really explain what provider means in this context. Is it the same meaning as .ddev/providers/ ? If not, maybe it should be changed to not overload that word, in addition to being a little more clearly documented in help. (Could be a follow-up).

Yes, to me it also not clear what provider in

ddev config [provider or 'global'] [flags]

really stands for, but It doesn't seem to be .ddev/providers what also was my first guess. Because of that I suggested prefixing the first argument like ddev config custom:local [flags], but maybe thats not necessary, because only global has any meaning as first argument.

@rfay
Could you clarify what provider in ddev config [provider or 'global'] [flags] stands for?

[rfay]

ddev config once supported provider like pantheon, but hasn't worked that way for a few years. The ddev config help is incorrect, should just say

  ddev config [flags]
  ddev config global [flags]

Want to take a shot at fixing it @h1nds1ght ?