Configuration management discussion on Drupal slack in the config channel
mpotter [Aug 28th at 9:26 AM] @mpp As one of the maintainers I still stand by that Blog. There is very little reason for normal projects to use Features in D8. I haven’t used it on a project in almost 2 years now. The only use case (maybe) is if you are building a product-like distribution (and really know what you are doing)
2 replies mpp [4 days ago] We’re looking into creating pieces of reusable functionality. It’s really hard to a) bundle the proper dependencies b) provide update paths for them. I was considering Features since a distribution would be too time consuming. There’s tons of config_* modules out there that all do part of the workflow but it would be great to have a best practice for this use case.
sdelbosc [4 days ago] I still need to write that but the features approach (though we end up not using features that much) is satisfying in my case: large factory of sites with different types of sites
mpotter [9:28 AM] Also, kudos to @nedjo for taking up Features maintenance for those that still want it. I was super happy to see the community step in and update the Drush 9 support for example (which I still need to do this week for Config Actions)
moshe [9:30 AM] ping me if you run into problems with drush9 port. hopefully the docs get you close https://weitzman.github.io/blog/port-to-drush9 Moshe Weitzman’s Blog Porting Commands to Drush 9 Drush 9 features a deep rewrite of our app, both user facing and internals. We created and open sourced AnnotatedCommand (example), OutputFormatters, and Config. We leveraged Symfony Console for our CLI fundamentals. For details on Drush9, see the video or slides from our Drupalcon Vienna presentation. Sep 28th, 2017 https://github.com/weitzman/blog/raw/master/assets/drush-port/core-requirements.png
gdd [9:30 AM] I’ve been really happy to see the contrib ecosystem continuing to grow around config management, and all the different ways people are using it
moshe [9:31 AM] We kept rewriting it until it worked well :slightly_smiling_face: You have a good point. Lots of innovation on top.
gdd [10:15 AM] Yeah, and that was always the dream, so its great to see it come to life
bircher [12:21 PM] @gdd too bad the meeting in Vienna didn’t end up happening, I would have been very interested in knowing what your plans or ideas for cross site configuration (ie for distributions/site factories etc) was.
gdd [12:45 PM] I feel like my feelings about that have changed three times since Vienna :)
moshe [1:30 PM] I guess its more complex than “if you want a Gallery feature, make a gallery module and ship your config files in there”?
gdd [1:31 PM] I think the use case we were talking about was “We have a platform with a distribution from which all sites are based and we want to maintain config differences on all the individual sites while at the same time being able to push out global updates to the platform”
moshe [1:42 PM] ok, that problem applies to .05% of config builders
gdd [1:43 PM] It applies to 100% of my clients
timplunkett [1:43 PM] that is very very common
moshe [1:43 PM] You guys breathe rare air
timplunkett [1:44 PM] c.f. every university
gdd [1:44 PM] Thankfully there are a lot of tools and best practices developing around that now Yeah its extremely common for any situation where there is a central authority with decentralized divisions (higher ed, gov, media companies)
moshe [1:44 PM] Yep, https://www.drupal.org/project/config_distro is the state of the art in this area, AFAIK. Have not tried it yet, but its a @bircher production so you can’t get any better. Drupal.org Config Distro Built on the same architecture as Configuration Split, Config Distro provides a framework for managing configuration updates from distributions. Requirements Config Filter Related The 8.x-2.x branch of Configuration Synchronizer provides filters that make it possible to use Config Distro to import configuration updates from installed modules and themes. How to Use it Install Config Distro. Mar 7th
gdd [1:45 PM] Yeah I mean back at Vienna I was kind of like “We should just manage it all with git merging and hope for the best” or “and config split away stuff we know will be different’
moshe [1:45 PM] Yep. thats what i built for bioraft. never launched for good reason (edited)
mpotter [3:51 PM] @gdd That is what I’ve been using Config Actions for. Sort of like scripted update hooks for config. We do config-import and then we run some actions that use partial config yml templates to merge site-specific stuff into the common config. I’m hopeful the CMI 2.0 API stuff will provide a better way for Config Actions to do that since right now it copies some code from the config installer that is private. We do use Config Split for some of the site-specific stuff also, but sometimes we don’t want to override an entire config item
gdd [3:52 PM] Yeah the nice thing about all of this is that so much of this is use-case specific, and the system is flexible enough that people can create the tools they need on top of it for their specific use case and now a lot of those tools are coming together and getting released and talked about “Now” = within the last year
moshe [3:58 PM] @mpotter so config actions runs its transform before the sync starts? so the sync has clean/final config to import? (edited)
mpotter [4:00 PM] @moshe No, you run config-import and then config-actions. Now the DB and sync config are different. You can do config-export if you have a site-specific sync dir (and after that you don’t need config actions). But if you only have a common sync folder for the sites you just allow it to be overridden on the site. (edited) Ideally with the new ConfigTransform stuff this would be handled more cleanly
moshe [10:57 PM] interesting.
mlncn [11:37 PM] joined #config.
Wednesday, August 29th  sdelbosc2:49 AM On my side where we are building a factory of sites that slightly differ based on brands or countries 2:49 AM We are exporting config into modules 2:49 AM Having some country or brands specific modules 2:50 AM In which we put the config overrides 2:50 AM and we have some utilities to do config updates that take care of overrides in hook update implementations 2:50 AM i.e. we don’t use full config export/import 2:51 AM even if not perfect, this gives us total control on what we need and we never got blocked on shitty situations that would require unclear workaround
mpp4:44 AM @mpotter how does core solve this: imagine the people admin view (yml) changed in core between 8.5 & 8.6, (how) does core update it?
bircher5:36 AM @mpp core doesn’t do that unless it is a schema change in which case update hooks are the only way. But core doesn’t provide an update path for sites started from standard and umami is only intended for demo purposes and has an explicit no backwards compatibility policy.
irmpds4:53 AM hello! Is there any plans for managing developer dependencies with config import? Maybe similar way to how composer does it?
bircher5:37 AM @irmpds yes that is the basic plan, but we need to agree/decide on what the limits to this are. ie what core is going to solve and what will be left to contrib
irmpds [3 days ago] Is there any place to get involved in discussion?
 Also sent to the channel bircher [3 days ago] There are two issues for this: https://www.drupal.org/project/drupal/issues/2830300 https://www.drupal.org/project/drupal/issues/2844681 I don’t know which is better suited for ongoing discussion, but both issues have a good discussion on the topic.  Drupal.org Allow development modules to opt out of config-export Problem/Motivation Everyone is having problems with modules being exported where they don’t want it to be. The canonical example is the devel module. Proposed resolution Add a key to a module’s info.yml file to allow them to opt out of config deployments. Remaining tasks User interface changes None API changes TBD Data model changes None Nov 24th, 2016 at 9:49 AM  Drupal.org Allow exported configuration to be environment-specific tl;dr: Something like Configuration Split… but in core. Problem/Motivation Drupal 8’s core configuration management allows me to export all configuration (or single files) and import all configuration (or single files), which is great. But one use case I run into quite often relates to how I develop Drupal sites. I often have at least a local development environment in addition to production. Jan 18th, 2017 at 1:06 PM 
 bircher [3 days ago] @irmpds (mention for skack notification which I only have turned on for direct ones in case you do too)
 irmpds [3 days ago] I’ll take a look! Thanks!