Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
We rebuild a container after every single module install. Perhaps we can do better.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#12 | interdiff-3185978-12.txt | 1.64 KB | dawehner |
#12 | 3185978-12.patch | 23.42 KB | dawehner |
#10 | interdiff-3185978.txt | 903 bytes | dawehner |
#10 | 3185978-10.patch | 23.37 KB | dawehner |
#8 | 3185978-8.patch | 23 KB | alexpott |
Comments
Comment #2
alexpottThis is very experimental but it halves the time to do a standard install from the command line. Some stuff will be broken as ConfigInstaller::checkConfigurationToInstall() is not firing but that should only affect a few tests. Let's see...
Comment #3
alexpottOn a standard non interactive install (ie. via drush, quickstart, or DrupalCI) this patch results in 39 less container rebuilds
Comment #5
alexpottThis fixes InstallUninstallTest... a green version of that is a good sign.
Comment #7
alexpottDrupalCi run 49 mins... compared to 57 mins on a recent run. I did expect test installation to speed up too because this affects the number container rebuilds done during \Drupal\Core\Test\FunctionalTestSetupTrait::installModulesFromClassProperty() too.
Comment #8
alexpottA little bit of progress to fix the config installer issue.
Comment #10
dawehnerI investigated two of the failures right now:
1.
testInstallProfileConfigOverwrite
Long story short, ... when determining, whether the module to install has conflicting configuration, we create a storage object for checking different collections ("", language.en etc.). This operation throws away the $folders information in InstallerStorage2.
ResolvedLibraryDefinitionsFilesMatchTest
As part of installing configuration we trigger a full rebuild of all available block derivatives. In order for this to be successful, the entity schemas needs to be installed already. This isn't the case with the current change, as now all configuration is installed before all entity schemas are installed.@alexpott Is it fundamentally needed that all configuration is now installed before the DB/entity schemas are installed?
Comment #12
dawehnerThis diff changes the way how entity schema is installed.
This now installs the entity schema for each module before it installs the configuration.
PS: There is a bigger underlying problem: It looks like the namespaces injected into the kernel during the installer contains already all modules, not just the ones which are already installed.
One approach which could be done is to reset the container completely during each installed module.
Comment #14
alexpottBy all the modules - you mean all the the module that will be installed - right? Yeah this was an intention - it needs all the namespaces in order to be built just once. We need the autoloading to work for that container compile. And yep this is a big change with likely side effects. I'm not sure we can land this as the default installer during D9 but maybe we can land it as an experimental installer then becomes the default in D10. I'm not sure. Sometimes I wished we didn't futz with the composer autoloader at all. So that
composer require drupal/module
would make it's code autoloadable it exactly the same way doing composer require for any non-drupal code works.Comment #15
dawehnerI totally follow your general idea ... as in, the autoloading should not be coupled to the process of toggling modules on or off, aka. the autoloading should be 100% purely based on composer for example.
From my perspective the main issue might be in the plugin system. Next thing I'll try is to dynamically change the plugin namespaces somehow.
Comment #16
andypost