CMI 2 meeting - 2020-02-05 [#3108084]

Meeting will happen in #config on drupal.slack.com.

Hello and welcome to this CMI 2.0 meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have an interest in advancing the configuration management capabilities of Drupal.
➤ Usually happens every other Wednesday at 16:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3108084`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Ping @bircher @alexpott @diosbelmezquia @mtodor @ricardoamaro @borisson @jcandan @marcvangend @Kingdutch @phenaproxima @balsama (Edit https://www.drupal.org/node/3108084 if you don't want to be pinged)

:three: Config Distro: updates

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

phenaproxima (he/him)	Adam in Boston, USA. Lurking :slightly_smiling_face:
alexpott	Alex in London (edited)
moshe	Moshe in Boston, Lurking
mtodor	Mladen here - Munich, DE. Thunder distribution maintainer and update_helper maintainer.
borisson_	:wave: Joris in :flag-be:, lurking.
bircher	Hi to all the people lurking :smile:Fabian in Prague
kingdutch	Alexander - maintainer at Open SocialI’m working on finishing the removal of features (and moving over to CMI) as we speak so may not be very contributive

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.

kingdutch

I think this is something that could benefit the ecosystem: [#3101832]Although I can understand for the Update Helper module it’s quite an undertaking (cc @mtodor)

2️⃣ Installing from config and install hooks of profiles

3️⃣ Config environment: review next steps

bircher	What do we do with https://www.drupal.org/node/2357215 and https://www.drupal.org/node/2982052 ?Maybe we want to add a new hook for profiles instead of making standard use hook_install_tasks to add a content or post install hook. Also maybe relevant #2924549: Invoke hook after a site install is complete if standard (and other profiles that like to be installed via existing config) would implement that hook it would be golden.
moshe	Feel free to tell me I’m oversimplifying, but I would rather recommend that install profiles ship with a module that does their install hook stuff. Ultimately, I think an install profile should be a composer.json and a list of enabled modules.
alexpott	that’d run into the same problems though. The problem is that during a config sync modules are installed prior to config entities being created.
alexpott	This is because modules (and therefore profiles) can have code that changes config on save.
alexpott	I’d love from profiles to not be modules and agree with @moshe that profiles should not implement module functionality.
alexpott	But I do think that providing install profiles with a hook that is trigger once installation is complete (whether by config install or regular install) is acceptable.
bircher	I agree, I think a hook that is called once a site is installed can work for both the profile and some modules (the issue linked above has use cases for it) that way we could do without install hooks in profiles
alexpott	I’m not 100% convinced about modules have access to this hook
phenaproxima (he/him)	Allowing modules to implement it seems dubious to me as well.
phenaproxima (he/him)	For reasons I can’t really articulate, though.
alexpott	I think it comes back to what @moshe says about profiles not being modules and I think the same applies the other way around.
phenaproxima (he/him)	That’s a good way of putting it. Allowing modules to implement a post-site install hook feels a bit like fuzzy boundaries.
alexpott	modules implementing this hook imply they care about the difference between being installed as part of an installation or being installed at a later point. But they shouldn’t care about that. And doing so will probably break some of the assumptions of allowing installation from config.
phenaproxima (he/him)	“Site install” really is the scope of the install profile in particular.
alexpott	As https://www.drupal.org/node/2357215 shows we can already do this via install tasks but I think the use case is prominent enough to make this simpler.
bircher	so if it is only the hook of the profile, could't we just not run the profiles install hook when running all modules install hooks and instead run it at the end of the site install?
bircher	ie where it runs when installing not-from-config
alexpott	We could but with all the time that has passed it is not inconceivable that some install profiles have config or optional config that depends on their hook_install() having been run.
phenaproxima (he/him)	Yeah, I was thinking that. It adds another “gotcha” to hook_install() (edited)
alexpott	If we’d started that way it’d be fine.
bircher	so in a non-sync install of a module the install hook runs after the config has been imported right, and the install hook of a profile is the same with it having run after the profiles config is imported.in a sync case (ie install from config modules hooks are called (we exclude the profile in the future patch) then the rest of the config is imported) then we call the profiles install hook after the config sync step, that would also happen. Didn't sufficient amount of time pass that profiles with install hooks could not be installed from config? Or couldn't we make this a Drupal 9 thing then?
bircher	I am not against a new hook, but with the new hook a profiles hook install makes no sense any more at all
alexpott	Install hooks run prior to a module’s config creation. I’m wrong. (edited)
alexpott	It’s that in a sync situation install hooks run prior to ALL config entity creation.
alexpott	I agree that once you have the new hook there is no use-case the old hook for profiles. But I see this as part of the move to make profiles and modules more different. And to show that this hook is special and triggered at a different time and in a different way.
phenaproxima (he/him)	:this2:
bircher	I can get behind that
bircher	then for D10 we can have no more hook install for profiles :smile:
bircher	3️⃣ Config environment: review next steps
bircher	#3033427: [plan] Add support for environment-specific configuration We moved the issues to 9.1 as that is a more likely target. Any interest in helping to move this along?
borisson_	So the next step here is #3048860: Create Config Environment API ?
bircher	yes
bircher	though I don't know how we meaningfully trigger the API and thus know that we have created value with it
bircher	without some UI that is
borisson_	I think we can make it so that we have an environment "prod" that disables views_ui / field_ui (we do this with config splits now) and with testcoverage we can ensure that those modules are disabled when we are in the correct env? (edited)
borisson_	Or is that too simplistic, do we need an actual use in core to be able to do this and should we merge the next issue in the list with this one?
bircher	well the environment only makes sense if you can switch to it right
bircher	so you need to be able to turn the split on
bircher	just setting it in settings.php is not enough, you also need to do a config import
borisson_	Yes, I agree because otherwise it doesn't do anything. But a test that does: $env = 'prod'; $config->import(); $this->assertModuleNotEnabled('views_ui'); should do that?
borisson_	I mean, there is no need for an actual UI to do that.
bircher	maybe that would be enough for the API issue. ie having that as a documented workflow, without a UI you would also configure the environment directly in the code.
borisson_	Yes, so we could eventually implement the UI as an additional module, because I don't think that I'd want people to be able to log in to a site and switch the "type" of env they are on.
bircher	good point, though for a development environment when you download the prod db you would probably want that, (in addition to a warning that you are not on the environment that you set in settings.php
bircher	exporting needs to happen for the environment the state is in and importing needs to happen for the environment the settings is in and then setting the new state at the end of the import process. I think that is a good start

4️⃣ Config Distro: updates

bircher	The issue re-imagining the API is in good shape, but we need someone who uses it on a real site to validate that the patch doesn't break their workflow
jcandan	Best I can do here is to say that I want to use it in a real site. But I'm lagging tremendously in getting it spun up.

5️⃣ Contrib projects updating to the new transformation API

bircher

config filter has a 2.x branch to bridge between its 1.x API and the new core API

6️⃣ Other contrib updates to share

kingdutch	If you want to peak at what we’re doing for Open Social in the removal of features, take a look at:https://github.com/goalgorilla/open_social/pull/1678https://github.com/g... still have some things to do to make the developer experience for updates better (using update_helper and config_distro). Also still considering whether we need drush cex and drush cim at all.
bircher	looks interesting!

Participants:

phenaproxima (he/him), alexpott, moshe, mtodor, borisson_, bircher, kingdutch, jcandan