-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
MAINT: remove choice of 'astropy' #72
Comments
I agree that "custom" would make it much more useful, even for affiliated if nothing else. But would that be too complicated to implement? I imagine you might want a combo at some point. Do you have a CLI API in mind? |
I'll separate the 'custom' out to another issue, I don't yet have a working API design in mind for it, and not sure have a capacity to implement, unless it becomes a blocker for other packages to use this. |
Well, So it is bad if this option is removed without an alternative. |
But do you really need to use that as opposed to |
Not sure. I (or someone) need to investigate but not today. Worst case scenario, |
Ah, I think |
|
There could be several ways to solve this, yes, but all of them would require code changes somewhere and needs to go through the PR period and so on. |
I certainly suggest a deprecation cycle for this, with e.g. falling back on |
I added this to infrastructure tag-up agenda for 2023-08-29 (though I am not sure if we will have quorum due to European vacations and such). |
This day and age I think there isn't more reasons to keep the
'astropy'
choice for remote-data. This would generize this plugin further.(OTOH, I can see that a
'custom'
choice could work where a domain could be specified, be that specific to astropy or scipy or whatever else)The text was updated successfully, but these errors were encountered: