Provide a basic "demo" CARMIN "interface" based on current shell

[yarikoptic]

The idea I have tortured @glatard at recent Interoperability workshop at McGill, so decided to "formalize" it a bit more. I am aware of https://github.com/CARMIN-org/CARMIN-server as a prototypical CARMIN server implementation. But I thought about a smaller/simpler one:
There could be a command line utility carmin which would take stdin as the load for PUT (where needed) and otherwise implement all API calls for the tasks in the current shell session. Could be a nice demo and "explanation" of CARMIN API based on concepts people could easily grasp.
Something along the idea of such a basic custom git annex special remote example which implements the protocol
I guess I might try to implement something like that just to get a better grasp of CARMIN

[glatard]

Awesome idea, not torturous at all! We might even reuse the python code developed for the CARMIN server, by-passing the web part of it. @louis-ver @simon-dube, do you think it would be feasible? What would be the right level to plug stuff in?

[yarikoptic]

With @kyleam we have started to implement something like that to get a better grasp of the CARMIN-API https://github.com/ReproNim/carmin-cmdline-demo . A "hurdle" of a kind is to some degree reliance on JSON for input -- does not really fits well with cmdline. And another one is that CARMIN is oriented toward "pre-registered pipelines" provided/exposed by the service. For the cmdline demo we thought may be we could then just create a single "pipeline" -- bash which would take a single option of the "command" as a string (or better a list of strings), but it would not know what are needed input files, nor before execution would know what files are output. If we were to trace it, then may be it could provide returnedFiles at the end -- the files which were generated during the execution. But also were not sure if that fits the idea here since pipeline seems need to describe all the input/output files... also some commands could modify files in place, which would not play totally along with isReturnedValue I guess which signals that file could be only either input or output.
Anyways -- we have postponed pushing it further ATM, but might come back to it later ;) Decided to share to see if it comes handy anyhow

[glatard]

For the pre-registered pipelines, a solution could be to store them in the form of Boutiques descriptor in some pre-configured directory. Then export Boutiques description to CARMIN objects through bosh export carmin boutiques.json carmin.json. I agree that a single bash pipeline defeats a bit the purpose of documenting inputs and outputs :) If a file is both an input and an output it could appear twice in the pipeline description, it shouldn't be a problem.