Change how distributions are handled

Isn't that basically what install-from-config is? https://www.drupal.org/node/2897299, if you combine that with a composer.json and a way to get the config, what else is missing?

I think there is a valid use case for distributions that are more than just an starting template. The way we handle our internal distributions and also projects like thunder IMHO are built is that they're more than just that, they are continuously developed and deal with existing sites as well as new ones.

I think the long-term plan from @alexpott is to deprecate the current install profiles in favor of that, I suppose it doesn't make a big difference if the final piece of setting things up is in a module or install profile install hook, I still have some reservations though, for example. we mostly stopped providing config overrides/default config for simple config, but it's pretty common for modules to add more configuration settings or change defaults, and then you have to be *very* careful on every module update to update your override/exported config accordingly. That's why we do most of our simple config changes now in hook_install() with PHP code to just write the settings we want to change.

I like every single proposal of that, especially 4-7. But I don't get, why this would make distributions (even more) starting templates?
I think the current implementation is already very much aimed at that concept. And for Thunder it is actually quite a hassle to provide the Distribution in a more product-centric way with updates and continuous improvements. And we actually also use code to do the config changes over time.
Nonetheless, I think all your ideas would streamline working on, and with, a distribution.

As for larger distributions like Thunder, the custom functionality would need to be moved into separate modules that would then be responsible for handling the config changes.

Ok. So, If you decide to be a starter kit distribution, you just provide config files and a composer file, but if you want to be updateable, you additionally provide a management module.

Hm, interesting.

I guess we would have to be careful with install from config though, we should not end up with all sites having the same uuid...

Nope, not easy. But you came up with this idea at a time where I am totally reconsidering the way Thunder handles itself and the projects that are based on Thunder.
So, I am very interested :-)

✅ +1 for this idea issue. I am not sure where we go with the implementation, but documentation on what is/isn't possible with install profiles, best practices, and things to avoid in the (relatively) new composer world would be a huge win.

✅ +1 for making the profile as lite as possible so that it is not another major upgrade activity for sites based on a profile.

Distributions be changed to be a "starting template" for building a site, after the initial installation everything would be managed by that site.

❓I am not sure how this would be true though. even having composer files with dependencies would require version bumps. Having an option to do it in a global location instead of every single site would be nice. e.g. use case would be to use the same version of drupal/redirect module on all sites created with the given install profile.
❓ This change would also mean site created using the install profile today would be different from the one created using the same profile in a month (as install profile got a new version with different modules or new version)

I guess we need a different solution for those on-going updates via a module or some other means?

It almost seems like if this is done right, it could overlap with Features.

I'm thinking having a starting point that enables a set of modules and a base starting config -- but if once that is installed, you no longer need the profile... then why not allow you to install another "profile" on the site to add additional config and modules?

Is it fair to say that recipes are addressing this?