Design of looper configuration

[nsheff]

With some proposed changes, including #343 and #342, it's time to revisit how looper is configured.

Right now there's a dotfile, which has some discussion here:

• https://github.com/pepkit/looper/issues/253
• https://github.com/pepkit/looper/issues/267

It's very simple, and just points to the PEP, which defines a looper section that configures looper.

(Aside: some related discussion in pephub, too, but there we changed it to .pep.yaml, with the point being that it was like an environment config file that marked this as a repo, that just points to a PEP. But I think this went away with the PEPhub switch to a database back-end.)

Next steps

Some brainstorming about how to configure looper:

• The new looper configuration could use this .looper.yaml file. It would expand to include all the looper configuration that previously happened in the PEP. For exmaple, it will point to a PEP and a pipeline interface.
• We will need a global config file to subsume the divvy config settings we had in $DIVCFG.
• Would it make sense to "register" the available pipeline interfaces in the global config? Then you could refer to them more easily in the local config, maybe? Probably not...
• we want to specify the pipeline in the config file for the repository, rather than in a global config.
• the linking to project will be different. Instead of making changes to the PEP, you'd adjust the looper config file.

Example idea for new config file:

output_dir: path/to/output_dir
pep_config_file: relative/path/to/project_config.yaml
pipeline_interfaces:
  project: path/to/project_pipeline_interface.yaml
  sample: path/to/sample_pipeline_interface.yaml

Disadvantages:

• this would not allow you to submit different pipelines for different types of samples. In the end, I think this is fine.

• would it allow multiple pifaces? It could.

• Wait for #342 (it would determine if we even need a separate looper config at all)