Conversation
|
It could also have a pre-determined set of observatories |
Codecov Report
@@ Coverage Diff @@
## master #1373 +/- ##
==========================================
- Coverage 62.19% 62.12% -0.07%
==========================================
Files 89 90 +1
Lines 20215 20241 +26
Branches 3650 3652 +2
==========================================
+ Hits 12572 12575 +3
- Misses 6857 6880 +23
Partials 786 786
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
| dest="directory", | ||
| help="Destination directory (set $PINT_CLOCK_OVERRIDE to this value to look here first for clock files)", | ||
| ) | ||
| parser.add_argument( |
There was a problem hiding this comment.
More conventional would be a --verbose (possibly repeatable) and optionally a --quiet rather than explicitly referencing log levels. Since this is a specific application, one might be able to select sensible log levels to correspond to these.
There was a problem hiding this comment.
That's the type of interface I had gone for initially for applications, but @scottransom wanted this method
There was a problem hiding this comment.
I'm a bit confused... What does --verbose have to do with a specified output directory or filename?
There was a problem hiding this comment.
And if the discussion is about the log levels, I was just thinking that we should be consistent with the other PINT command line programs. Maybe --verbose could correspond to upping the log level by one, as well. (maybe by one for each verbose added).
There was a problem hiding this comment.
Yes, this is about log levels. I'm not sure users of a command line program will have any idea what log levels have to do with what output they want to see. Making --verbose bump up the log level, and --quiet bump it down by one might be a tidy way to present a more conventional command-line interface.
There was a problem hiding this comment.
Yes, this is what I had implemented months ago. I agree it's more standard but I don't really care either way.
|
It's worth pointing out that I don't think this is relevant to #1372 - that is a request to be able to preload the astropy cache for use by machines without internet access (or containers that should minimize calls to the internet). It might have some use for non-PINT users who just want to pull out the clock files without having to face a line of PINT code? |
|
OK, if this doesn't do what #1372 wants (I thought it could, since it would then not have calls to check all of the clock files over the internet, but maybe I'm misunderstanding) then it's fine to close |
I think @JPGlaser would have to confirm for sure, but we've discussed it before and the problem is how to pre-populate the Astropy cache for use on cluster nodes that will not have Internet access. I've added many more comments to the issue. |
|
Should we close this, or merge it? |
|
I don't know how useful this is - I'm not sure I have a use case in mind for it. It's not much code, though, so if it had tests to ensure we didn't break it then it wouldn't do any harm to include it. |
|
What is the status of this? |
|
Still tabled. I think it works for what it is, but it's not clear that it's what's needed. |
5 participants
I think this is what was requested in #1372 . But I don't know if a better implementation is available.
Usage:
So this runs as an executable script. It could also be made into a standalone function if needed, although what is needed for that is very simple.