Dont check file paths in settings when doing case suite copying

[onufer]

There is a file-exists check that happens in copyInterfaceInputs(); but this is not necessary when just copying, it is necessary when trying to run.

[john-science]

There are definitely times when this feature is necessary.

I suppose we could pass an optional argument to the function to allow for non-existence.

[keckler]

There is another similar situation that is common in our workflow when submitting a case suite where some of the cases have dependencies on others. If a later case depends on files that will be generated by one of its dependencies, error messages that don't really make sense are printed at the time of suite submission because those files don't yet exist.

Minorly annoying, but not a huge deal.

I'm not sure if this is the same thing that @onufer is talking about or not.

[john-science]

@onufer

@ntouran 's suggestion here is to add a new flag to the CLI entry point you are using.

For instance, if this only shows up on a "clone" command, I would add the optional flag --missingFilesOk to that, which defaults to False.

In this way, you can get rid of all the bothersome warnings, but we don't generally reduce the code safety.

I like the idea.

Thoughts?

[opotowsky]

Ok we discussed this more offline, and the scope has shifted a bit.

The original issue is still the case sometimes (like what Chris mentioned with case suites that have dependencies), and so moving the warnings from INFO to DEBUG will be the path forward there.

But there's another layer to the issue we discussed yesterday. When CaseSuites are cloned, the files in the settings file that are relative file paths are copied into the case run dir and the setting is updated to an absolute file path. If the case run dir upon completion is moved somewhere (or some other change to the dir structure is made), then a user will get a failure on, e.g., loading the DB after the fact. Various (absolute) filepaths in the settings no longer exist, after all.

The solution:

We will edit copyInterfaceInputs to return the filename (i.e. a local relative file path) when a file is copied into the run directory. When a file is provided by the user as absolute, nothing changes (all that happens is the file check passes and cloning continues). The latter situation presumes these absolute file paths aren't changing as often as the dir structure of case runs.

I plan to test the above with a standalone case submission with both absolute and relative file paths, as well as a case suite with both abs and rel file paths. Mark also has a suite builder I will test. So this shouldn't be too dangerous to merge.

[onufer]

looks good to me too!