Create fetcher.settings.php file instead of settings.php and include it.

That workaround seems really kludgy to me though.

Currently the entire settings.php file is uncommitted, so I'm not sure how critical that would be, and the idea is that you would commit the change to settings.php once it's made and fetcher would never need to add it again. In fact, you could replace the need for the site-settings.php file and just use the settings.php file for that (as almost everyone does). Some organizations have rather complex / refined settings.php files, so to use it with fetcher w/o extra work, you have to move those files into a new file called site-settings.php and let fetcher create the settings.php file for you... a process that isn't obvious for someone new. Then if you want to deploy that code using your own scripts or another vendor, you're missing your custom settings.php file.

Seems like fetcher should be less obtrusive.

How about just creating a fetcher setting for what to name the settings file that fetcher creates? Then, a site's yaml file could make the call?

..not sure why that seems like a kludge, though it definitely makes it hard to share the config that *does* belong checked in between environments.

Yeah, it's certainly that, and that many people are used to using sites/default so it's a clever trick, but adds a confusing element that isn't obvious to someone new to fetcher (or even me who's been using it a while)

Many companies avoid checking in settings.php, some using a site-settings.php equivalent and some advocating an [environment-name].settings.php pattern. A few inverse the relationship and check in a settings.php with the shared stuff and then require an ephemeral file that's kept out of VCS from settings.php. Unfortunately I don't think there's a clear pattern or best practice.

Yup, I've used both variations, but there IS at least one common and necessary denominator of either approach, settings.php. It really doesn't matter which method is chosen because a settings.php MUST be there for anything to work (whether it's ephemeral or not). So fetcher could take these steps in it's ensure tasks for example..

1) Ensure that a settings.php exists. If not, create one by copying the default.settings.php file.

2) Check if $database['default'] is set and not empty OR if the fetcher environment variable is not set. If it is, create a fetcher.settings.php file (with JUST the necessary
$database['default'] settings AND/OR the fetcher environment variable.)

3) Check if $database['default'] is set now. If not, add the include snippet to the end of the settings.php file.

In this way, fetcher only does what's necessary and nothing more to get the site up and running, and however other people want to deal with their settings.php is totally up to them and not fetcher's concern other than filling in pieces that it finds missing.

So fetcher.settings.php would not replace site-settings.php, you'd instead be either committing that stuff to settings.php instead or you might want the environment specific includes I mention above.

Yup, like I said above:

In fact, you could replace the need for the site-settings.php file and just use the settings.php file for that (as almost everyone does).

If they were using an ephemeral settings.php and adding an include manually before when setting up a site. They can still totally do it manually each site setup like they did before, but fetcher will at least create the settings.php file for them first... OR they can configure the fetcher settings to include the file directly... OR they can create a site-settings.php file for that stuff... OR they can just check-in their settings.php file and put code above or below our snippet depending on the order they want to do things and if they need the environment variable or not. If they have their own custom deployment scripts, then fetcher should still be able to play along nicely.

The other nice thing about this method is that I'm pretty sure it would be 100% compatible with both existing fetcher sites and ones being added to fetcher because if they don't have a settings.php file, fetcher will create one that includes fetcher.settings.php file in the process. If they are an acquia/pantheon site, fetcher will add the snippet to the end (which will show up on your next git diff, thus highlighting the change!) If you've checked in your entire settings.php file with db credentials that you share locally and on the server, you are probably a crazy person, but whatever, fetcher will play along with your madness and not overwrite your db credentials in fetcher.settings.php.

How about fetcher.temporary.settings.php ?

I like "fetcher" because it gives you a hint about how the hell it was created, and "temporary" clarifies that you probably want to not commit it to VCS. and then "settings.php" so you also know what it's related to.

Also how about being even less obtrusive and making the default snippet be something like..

  # Grab the fetcher settings if available;
  if (is_file(dirname(__FILE__) . '/fetcher.temporary.settings.php') {
    require_once('fetcher.temporary.settings.php');
    $database['default'] = (!empty($database['default']) ? $database['default'] : $fetcher_temporary_settings['database']['default'];
  }

.. so fetcher isn't even overriding the database creds directly, but allows you to use the variables as you wish if you want to modify the snippet to your own needs / logic.