OS Adaptive Project Scripts

[grayside]

In phase2/generator-outrigger-drupal#61 we encounter the issue originally brought up by @mike-potter in the original project scripts PR about supporting multiple OS's.

Background

I opposed the particular structure proposed then, punting on the solution:

scripts:
  doit:
    alias: it
    default:
      - cd somewhere
      - cp source dest
      - ls source
    win:
      - cd somewhere
      - copy source dest
      - dir source

We also had a proposal to prefix individual steps with some OS-specific adaptations:

setup:
  alias: setup
  description: Run the end-to-end repository initialization and site install script.
  run:
  - rig project run:welcome
  - rig project sync:start
  - start.sh
  - linux-gnu:  COMPOSE_FILE=build.devcloud.yml
    default: COMPOSE_FILE=build.yml
  - linux-gnu: one-thing 
    osx: another-thing
    windows: yet-another-thing

However, now we are stuck with confusing and limited hacks such as script steps of:

 if [ "$OSTYPE" == "linux-gnu" ]; then COMPOSE_FILE=build.devcloud.yml; else COMPOSE_FILE=build.yml; fi

I originally resisted having our "steps" sub-divided into OS because I felt like that was a too-limited approach to overrides.

1. Other parts of the file might need overrides in the future. For example, I'm working on a rig project doctor mechanism which will allow "diagnoses" to be added to the outrigger.yml file, and I can certainly imagine wanting to add some of these which only apply to a given OS.
2. OS steps not relevant to you are distracting.
3. Other types of overrides matter, such as project environment overrides, local environment overrides.

As a general challenge developers need a way to see the configuration that actually affects their system (not unlike the way docker-compose config command can spit out what is active and relevant).

Proposed Solution

I think the forward-looking approach, and the one we've been training developers to think about already with our use of docker-compose, is to follow the docker-compose practice here.

• outrigger.yml contains the default practices. As a matter of convention we can steer these towards OSX if we want.
• outrigger..yml is auto-detected relative to outrigger.yml and merged on top. (Downside: scripts whose steps we want to amend need to be complete in the overriding file.)
• outrigger.override.yml or outrigger.local.yml can in turn override all that.
• Future Goal: A rig project config command loads the config which will be in use and renders it to the terminal to review what's actually happening.

This approach sets us up to have a more versatile config merging mechanism.

Next Steps

We need to select a direction and pull it together. In the meantime it's my intention to proceed with the ugly hack, as the broken state of the existing released generator is causing us problems with Linux users who are learning to end-run our stuff.

[grayside]

Discussed with @febbraro and @mike-potter, we're going to go with an override approach. I will update the proposal above with the refined details.

[grayside]

The go-task project has an ability for OS-specific overrides to a YAML-configured task execution system.

Reads the general-purpose file, then the OS-specific file, and uses the Mergo library to combine them.

Example: https://github.com/go-task/task/blob/48bf09da211a48cd3c3e4094135bacab877ea462/taskfile.go#L14