There is a fundamental design discussion we should have about protecting the user against potentially impossible requests. The main reason era5cli exists is to facilitate a data request easily in a workflow, not to make sure a request is solid. There are various checks on the call done at the moment, but they are diffuse and scattered throughout the tool. We could take this two ways:
- We implement a single "request checker" that applies all checks (i.e. are the variables correct; are variables possible given the time frame of hourly or monthly; are there no impossible combinations of flags, etc) in one place, so a clear overview gets created and checks are not duplicated or missed.
- We do not wish to validate a request but simply translate a quick CLI call into an API request, and let CDS determine whether this results in data or not. This means we will keep the checks inside the tool to a minimum.
There are middle grounds here and combinations, of course, but this is a fundamental conversation we should have that will inform further development.
There is a fundamental design discussion we should have about protecting the user against potentially impossible requests. The main reason era5cli exists is to facilitate a data request easily in a workflow, not to make sure a request is solid. There are various checks on the call done at the moment, but they are diffuse and scattered throughout the tool. We could take this two ways:
There are middle grounds here and combinations, of course, but this is a fundamental conversation we should have that will inform further development.