In process_function take nnpdf31_process from PLOTTING_*.yaml

[RoyStegeman]

addresses #1288

[Zaharid]

A couple of things need to be done here:

• We have higher level functions for recovering the plotting file information, specifically validphys.plotoptios.get_info. See e.g.

  nnpdf/validphys2/src/validphys/config.py

  Line 1466 in 9467c25

  metadata = get_info(cd)

  Also ideally this would not touch a Loader and instead recover a commondata object, but looking at the uses of this function that might be involved.

• In the code triggering the warnings in comparefits, specifically

  nnpdf/validphys2/src/validphys/config.py

  Line 767 in 9467c25

  (process_lookup(dsin.name), dsin.name): dsin for dsin in data_input

  we should definitively use the get_info lookup (also I was not too happy about adding anything related to processes there but not looking at what that breaks).

[RoyStegeman]

we should definitively use the get_info lookup

Sure, in the config Class everything is already there to do that instead of the process_lookup, but that's not the case for the other instances of process_lookup.

Also ideally this would not touch a Loader and instead recover a commondata object

Not really sure what you mean here. A commondata object is alsways obtained through a Loader at some stage, right? Both the lines you point at are inside CoreConfig, while process_lookup is called outside that class in most cases so the commondata object is not as readily available there.

[RoyStegeman]

@Zaharid could you clarify your points above?

[Zaharid]

we should definitively use the get_info lookup

Sure, in the config Class everything is already there to do that instead of the process_lookup, but that's not the case for the other instances of process_lookup.

Also ideally this would not touch a Loader and instead recover a commondata object

I meant that line specifically, which is used in a lot of code paths.

Not really sure what you mean here. A commondata object is alsways obtained through a Loader at some stage, right? Both the lines you point at are inside CoreConfig, while process_lookup is called outside that class in most cases so the commondata object is not as readily available there.

I like the idea of having some separation of concerns between what happens before and after the graph runs. Stuff like funding appropriate paths to commonda happens before as of now. On top of the (arguable) theoretical purity, it does enable certain features, like for example allowing to override the commondata lookup for the purposes of closure tests. That works because there is a single point that knows how to get the commondata(spec) and knows how to handle that keyword. I suppose it is mostly inconsequential for the remaining uses, but would be good if it wasn't needed.