Handling AvailableData entries that end up as RemoteData

[GeigerJ2]

Problem is that RemoteData behaves like RemoteFolderData. Thus, we cannot specify the path to a file in our Sirocco input YAML files, because otherwise, the CalcInfo object created by aiida-shell contains instructions such as:

meaning that the provided filename is assumed to be a directory name, and its contents are copied over/symlinked to the running directory. For initial_conditions, there are no contents, as this is actually a file, thus, nothing is copied over/symlinked to the directory where the dummy ICON task is being run, and the task fails.

Changing the spec in our YAML file from:

         src: /mnt/home/geiger_j/test/sirocco/data/initial_conditions

to

         src: /mnt/home/geiger_j/test/sirocco/data/

Fixes it for now, but is not really a viable long-term solution, as the initial_conditions key in our example:

data:
  available:
     - initial_conditions:

just happens to be the filename we want to symlink, however, it could be anything, as it's just a reference to the cycles section.

Notes

• Resolve src of script to be run on remote Computer by copying over?
• Take into account filenames argument for launch_shell_job
• Set symlink true by default for remote data, rather than copying the files
• Resolve environment source files -> They should be local and copied over, right? Currently, they are put into _aiidasubmit.sh with the absolute paths on the local machine
• Input keys in the YAML file, e.g., initial_cond here:

      tasks:
        - icon:
            inputs:
              - initial_cond:
...
data:
  available:
     - initial_cond:
         type: file
         computer: thor

end up literally in the call to the script, e.g.:

'/mnt/home/geiger_j/test/sirocco/icon.py' '--restart' '--init' 'initial_cond'  > 'stdout' 2> 'stderr'

Thus, they must correspond to the actual filenames. Do we want this constraint?

[GeigerJ2]

Should be fixed by sphuber/aiida-shell#109.

[GeigerJ2]

Superseded by #136.