Contrib.social

Installing via drush with --existing-config flag requires setting farm.modules=[]

Open on Drupal.org →
Created on 2 March 2024, 10 months ago
Updated 21 May 2024, 7 months ago

Problem/Motivation

farmOS implements hook_install_tasks() to add a custom farmOS module selection form to the Drupal installation UI, allowing the user to select which additional farmOS modules they want to start their instance with.

It also provides a farm.modules installation profile argument that can be used to specify modules from the command line during drush site-install. This accepts a JSON-formatted array of module names, or a shortcut string that corresponds to a set list of modules (all, default, base).

This is helpful for the reasons described above, but it introduces a behavior that is not provided by Drupal normally, and in the context of a codebase that uses Drupal configuration management it creates an additional and unusual requirement.

In order to use Drush to install a farmOS instance with managed configuration, you must explicitly set farm.modules to an empty array:

drush site-install --existing-config ... farm farm.modules=[]

(Note: the farm argument before farm.modules is the desired installation profile (see https://www.drush.org/12.x/commands/site_install/#arguments). It is necessary to include this in order to set farm.modules. Ideally neither of these would be necessary because config/sync already has the desired installation profile and installed modules.)

If you do not include "farm farm.modules=[]" at the end of the drush site-install command, then it will automatically install the default set of modules. If you are managing configuration, this means that a whole bunch of additional modules will be installed beyond what is declared in config/sync/core.extensions.yml and you end up with a new instance that immediately has overridden configuration.

Steps to reproduce

Install a farmOS instance with managed configuration via drush site-install --existing-config without adding farm farm.modules=[] to the end of the command. Observe that all default farmOS modules get installed.

Proposed resolution

I can see two potential ways forward.

  1. We may be able to simply modify the existing code so that omitting farm farm.modules=[] in drush site-install defaults to NO additional module installations. Not sure exactly how... need to consider how that list is being fed in from the module selection form's default values.
  2. A broader solution would be to remove the custom module installation options from the Drupal installation steps entirely.

Personally I am leaning towards exploring #2, for a few reasons:

  1. It would make drush site-install --existing-config work as expected.
  2. It would remove code/files from the repository root that are currently only there to support this extra module installation step.
  3. We already provide a form for enabling modules after the site is installed via the farm_settings module.

Regarding that last point: instead of offering a duplicate module installation step during initial instance install, what if we directed users to the module installation form as a first step AFTER initial install? Or even better, what if we create some kind of "Initial setup wizard" that includes module selection as one of its steps? This could open the door to a lot of ideas/improvements to initial setup/onboarding, which farmOS desperately needs IMO. And we've already taken a small step towards that by adding the "Setup" section (https://github.com/farmOS/farmOS/pull/706). Maybe we just need to wrap some of those things up in a "multistep wizard" that is the first thing a new farmOS site administrator sees after installation.

These are probably multiple separate bugs/feature requests that deserve their own issue, but I figured I would at least start this one as a "bug report", to start the discussion...

Also, I think removing the farm.modules profile argument would be a breaking change, because it would change the behavior of automated drush site-install commands anywhere they are used (eg: automated tests, local testing environment automations, etc). So this would not be able to happen until farmOS 4.x at the earliest...

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

🐛 Bug report
Status

Fixed

Version

3.0

Component

Miscellaneous

Created by

🇺🇸United States m.stenta

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @m.stenta
  • Comment 10 months ago →
    🇺🇸United States m.stenta

    It also provides a farm.modules installation profile argument that can be used to specify modules from the command line during drush site-install. This accepts a JSON-formatted array of module names, or a shortcut string that corresponds to a set list of modules (all, default, base).

    ...

    removing the farm.modules profile argument would be a breaking change, because it would change the behavior of automated drush site-install commands anywhere they are used

    If we do remove this option, then we will need to provide another option for these automations. Otherwise, it will not be able to test "installing all modules" like we do currently in our automated tests (among other cases/contexts):

    https://github.com/farmOS/farmOS/blob/a07034f18a5091dc91fab2360509126ef0...

    Perhaps an alternative would be to provide a drush command for installing "sets" of farmOS modules (eg: all, default, base). This could then be run after site installation as desired.

    For example:

    drush site-install --existing-config
drush farm:install-modules all

    This could be split off as a separate feature request and implemented before farmOS 4.x.

  • Comment 10 months ago →
    🇺🇸United States m.stenta

    This would also allow us to remove a "temporary" workaround that was put in place to fix #3183739: Functional tests are installing all default farmOS modules → .

  • Comment 10 months ago →
    🇺🇸United States m.stenta

    One thing that needs to be figured out: how do we install the "base" modules in instances that do not have managed configuration? Right now that set of modules is not shown in the modules form, and just gets installed by default, unless farm.modules is explicitly set to an empty array.

    I think we basically want the behavior to be:

    1. If the site does not use managed configuration, automatically install "base" modules.
    2. If the site does use managed configuration, do not install "base" modules.

    Maybe we need to rethink this idea of "base" modules more generally. Right now they include:

    • farm_api
    • farm_login
    • farm_settings
    • farm_setup
    • farm_ui
    • farm_update

    According to the comment in farm.profile: "Base modules will always be installed, but can be uninstalled."

    We can't make them hard dependencies, because you may want to uninstall them in some cases, for a more customized experience.

    So how do we ensure they get installed for the "default experience" (when managed configuration is not being used)?

  • Comment 10 months ago →
    🇵🇱Poland wotnak

    A quick fix could be to just check in the custom install task if $install_state['parameters']['existing_config'] is true and if so skip automatic installation of base modules.

  • Comment 10 months ago →
    🇺🇸United States m.stenta

    I like that idea @wotnak.

    Maybe we can still think ahead to some of the larger changes, but a quick fix in 3.x would be worth it.

  • Status changed to Needs review 9 months ago
  • Comment 9 months ago →
    🇺🇸United States m.stenta

    I created a PR that implements @wotnak's suggestion: https://github.com/farmOS/farmOS/pull/821

  • Status changed to Fixed 8 months ago
  • Comment 8 months ago →
    🇺🇸United States m.stenta

    PR was merged.

  • Comment 7 months ago →
    System Message

    Automatically closed - issue fixed for 2 weeks with no activity.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024