[config] `before`

[tristan-f-r]

This is an approach to a generalized implementation of #274. As intended by #261 for thresholding, we introduce the concept of a spras key which holds spras-specific parameters. Specifically, we want to include before.

- name: meo # as established in the discussion below, this is a bad example. See D'or for better motivation.
  params:
    include: true
    run1:
      include: true
- name: pathlinker
  params:
    include: true
    run1:
      spras:
        before:
          meo: [run1]

Essentially, algorithms can now specify algorithms that they want to run before the current algorithm, for pre-processing of the passed in interactome. However, as it stands, all PRAs only return a ranked interactome.

Thus, to resolve this issue, we rework parse_outputs to allow specifying Weight instead of Rank (but algorithms need to specify one or the other). This has a few benefits:

• We can detect if an algorithm supports being a before algorithm if it specifies a Weight. (Though, this information should be typed: perhaps we may want to create newtypes around these different outputs?)
• We don't need to do any kind of extra work on the other parse_outputs nor declare algorithms as some special 'preprocessing' algorithms.

This allows us to support orienters, interactome pruners, and even re-weighers as a general suite of preprocessing for PRAs.

This can also be used with lighter preprocessing functions, as suggested in #139.

[ntalluri]

I'm confused about the example, why would we potentially need to run MEO before pathlinker (or any other pathway reconstruction method).

[tristan-f-r]

MEO was a bad example here, since it both orients edges and does pathway reconstruction. There are other orientation algorithms (#162 and #269) that provide better motivation.

[tristan-f-r]

Just to replicate a conversation on Slack, this actually might be a good idea to remove the 'deterministic'ness of deterministic algorithms: there are some algorithms that are deterministic because they depend on the order of the input. We can have some preprocessing before that uses a seed (through the #335 pipeline) to reorder the input, allowing us to get some randomness back from deterministic algorithms.