I have got spoiled by datalad run to provide me commit messages which provide immediate information about what command was actually ran, intended inputs/outputs etc. Even if not machine readable (although I do not yet see why not), I think reproman run commit message should become as or even more informative.
As discussed, reproman run is not using datalad run and results are not necessarily could be just datalad rerun. Some, local invocations could probably be mapped into pure datalad run invocations, but no need/use-case for that ATM. What I am thinking, shouldn't we then just come up with a [REPROCMD] ... or alike with a similar to datalad run json record which would include all the arguments specified to the reproman run (analogous to what datalad run does), and also points to the job file with further details of this exact invocation. Such record would be super informative to user (me), would immediately tell me where and how I ran it, as ATM datalad run record does.
ATM it is just e.g.
I have got spoiled by
datalad run
to provide me commit messages which provide immediate information about what command was actually ran, intended inputs/outputs etc. Even if not machine readable (although I do not yet see why not), I thinkreproman run
commit message should become as or even more informative.As discussed,
reproman run
is not usingdatalad run
and results are not necessarily could be justdatalad rerun
. Some, local invocations could probably be mapped into puredatalad run
invocations, but no need/use-case for that ATM. What I am thinking, shouldn't we then just come up with a[REPROCMD] ...
or alike with a similar to datalad run json record which would include all the arguments specified to thereproman run
(analogous to whatdatalad run
does), and also points to the job file with further details of this exact invocation. Such record would be super informative to user (me), would immediately tell me where and how I ran it, as ATM datalad run record does.