You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From the same discussion as #166 with @mbercx and @superstar54, also came this issue: I'm getting quite confused these days with all the string annotations one needs to correctly set up. They seem a bit cumbersome and repetetive, e.g., having to specify:
for using a custom parser when running a ShellJob. In this case, I propose we make the "name" key optional, and allow users to just specify a list (or, make the argument fully optional and inspect from the parser actual outputs of the parser function, though, that might be just wishful thinking, as it's passed as PickledData). I understand that other options could be specified here, e.g. data type, so we need to find a balance between extensibility and ease of use, so the default could be "name", while other/multiple identifiers can still be used.
There are more places where one has to add such string identifiers, the "General" comes to mind, e.g., from here:
In principle, it's from the RTD on Transferring WorkChain to WorkGraph, but I just checked, and actually it uses "name", not "General". Might have been an older version I still hadn't updated on my laptop. In any case, then the "General" issue is void if it's dropped 👍🏽
From the same discussion as #166 with @mbercx and @superstar54, also came this issue: I'm getting quite confused these days with all the string annotations one needs to correctly set up. They seem a bit cumbersome and repetetive, e.g., having to specify:
for using a custom parser when running a
ShellJob
. In this case, I propose we make the"name"
key optional, and allow users to just specify a list (or, make the argument fully optional and inspect from the parser actual outputs of the parser function, though, that might be just wishful thinking, as it's passed as PickledData). I understand that other options could be specified here, e.g. data type, so we need to find a balance between extensibility and ease of use, so the default could be"name"
, while other/multiple identifiers can still be used.There are more places where one has to add such string identifiers, the
"General"
comes to mind, e.g., from here:where
"General"
could also be the default and users could just provide a simple list, as I think came already up on our firstWorkGraph
coding dayThe text was updated successfully, but these errors were encountered: