-
Notifications
You must be signed in to change notification settings - Fork 320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistency in offline tools to abort if a file to be read doesn't exist and abort if a file created already exists... #1622
Comments
Here's an example error that I saw testing subset_data that shows an example error that's difficult to decipher.
|
I agree - both of these are good ideas. Thanks for starting this discussion. |
@negin513 had a great point that another option would be to add an override option "-o" that would allow existing files to be overwritten for existing files. |
Adding next here to discuss if we should go through the tools and ensure this is true as well as map out a plan for steps to make it happen. |
This is a usability issue that may be nice for the release, but needs to be discussed later? |
I'm just elevating this to a discussion. I think the behavior of our offline tools should be that files to be read in are first checked for existence. If they don't exist -- the tool aborts with error explaining that the file doesn't exist. This is helpful to do since the error message given when a tool finds a problem can be hard to decipher.
Similarly if a file is going to be created, and it's going to overwrite an existing file, that file existence is checked for and it will die with an error alerting the user that the file exists. So then the user can delete the file, or rename it in order to allow creation of the new one. This is in contrast to CTSM which will just overwrite files. But, that's helpful because the list of files is long and it can happen after running for some time. Here for offline tools where the number of output files will be small, I think this makes more sense.
If we agree to this behavior we can add this to:
https://github.com/ESCOMP/CTSM/blob/master/doc/design/python_script_user_interface.rst
It is a user-interface behavior that it's good to have a convention around.
The text was updated successfully, but these errors were encountered: