SortingAnalyzer doesn't respect order of compute in case of nodepipeline + non-nodepipeline code

[zm711]

MRE

analyzer.compute(['random_spikes', 'waveforms', 'templates' , 
'noise_levels', 'spike_locations', 'spike_amplitudes', 'principal_components', 'quality_metrics'])

Problem

It will calculate the non-node pipeline first despite the fact that to do all quality_metrics requires things like spike_amplitudes.

Solution

I know in the code it separates out the code into the two streams of pipeline and nonpipeline, so maybe we just need to document that this will happen? I mean we could also try to have something more intelligent that sorts this out, but with the current state I don't know think there is an easy solution.

[alejoe91]

@zm711 this is a very tricky point. Currently, the only extension that optionally depends on others is the quality_metrics. IMO, for simplicity, we could hard-code the quality metrics as post-pipeline. Alternatively, we could add and optional case in the depends on (e.g. depend_on="noise_levels|spike_amplitudes[optional]|spike_locations[optional]" and have a pre-pipeline and post-pipeline computation.

@samuelgarcia what do you think?

[samuelgarcia]

I agree with Alessio solution with pre and post pipeline but we are a bit busy now to make it so I would hard code the quality metrics after the pipeline with a very clear comments that it is temporary.

[zm711]

This sounds good to me. I know how to avoid, I'm more worried that others will do these commands and not understand why qm is failing. I'll check out the PR.