-
Notifications
You must be signed in to change notification settings - Fork 76
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
consider alternative names for search_data
and search_datasets
#770
Comments
I agree that we should consider alternative function names. My preference would be to use the prefix |
I have no strong preference on search v find, but I am curious what reasoning underlies your preference @chuckwondo? |
Aside from it being 2 letters shorter, in previous contexts, I've often seen DB client APIs using |
Thanks for expounding! |
I like the idea of aligning with STAC, a while ago Scott suggested that and I think it'll be valuable to avoid cognitive load from users, the one thing I'm afraid is to deprecated existing names. I think we should try to not break the API to the extend possible while encouraging people to use the new conventions. See: #221 |
I know this has caused confusion in the past, even as others at NSIDC have come up to speed on the library, so I fully support updated names here! I like what @itcarroll proposed to align with STAC. We may also want to consider the language most commonly used within the NASA Earthdata ecosystem. You can't have Earthdata Search without "search", for example, so I'd be more keen on using this vs "find". As an aside, this seems like a great use case for #761 too. |
Just to clarify, is this the current proposal?
If so, +1 from me. |
🚀 💯
+1
I do worry that having multiple aliases for common features could lead to confusion, as people might think they do different things. I really like having "one correct way". I do believe a long deprecation period would be in order for top-level API things. We need to probably have deeper discussions about how to communicate around time-until-deprecation. Should we always include a minimum date in our deprecation messages, e.g. Related #766 |
I like the alignment of |
@mfisher87, after looking at the proposed new names again -- This analogy might be a bit of a stretch, but consider the case of security procedures at a place/event, where people may be subject to a "bag search." In that context, nobody is searching for bags, they are searching within bags (for banned "items"). Thus, the security folks running a Thus, I would argue that a "collection search" implemented by a function named
@andypbarrett, I agree that "items" is perhaps too generic for many folks. Although "collections" is perhaps no less generic a term, anecdotally, it may feel more specific to most folks dealing with this information. I don't have any particular preference or suggestion for a better term than "items," but if you have any suggestions, please share so we can "vote" on it here. |
💯 This is an excellent point. I'm on team find now :) |
~ @mfisher87 in #769
Since "granules" is not very generic either, an option borrowed from the STAC spec could be "search_collections" vs "search_items".
Seems like a Milesone 1.0 change though ...
The text was updated successfully, but these errors were encountered: