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 runto 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 runcommit message should become as or even more informative.As discussed,
reproman runis not usingdatalad runand results are not necessarily could be justdatalad rerun. Some, local invocations could probably be mapped into puredatalad runinvocations, 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 rundoes), 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.