-
Notifications
You must be signed in to change notification settings - Fork 224
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
List of GMT aliases #48
Comments
Crossreferencing GenericMappingTools/gmt#2079 and https://forum.generic-mapping-tools.org/t/standardized-human-readable-gmt-parameters-for-pygmt-matlab-julia-pyshtools-etc/77. I see that GenericMappingTools/gmt#230 was merged last year (Dec 2019), does that mean there is a standard source for long aliases now? |
GenericMappingTools/gmt#230 was merged, but the long name feature is disabled by default. So the feature is still experimental and the long names can still change (for example, GMT uses |
I think we can solve this by adding a link to https://docs.generic-mapping-tools.org/dev/devdocs/long_options.html#common-options in the contributing guide. |
Why do we want to add the link in the contributing guide? Should we just wrap up all aliases in the pygmt/pygmt/helpers/decorators.py Line 15 in 1fb9e2e
|
Is it decided that the current names of core GMT aliases will be used for all pygmt common aliases? #764 indicated that incols and outcols will be used; there's also distcalc versus spherical and possibly other common options that are wrapped in individual modules rather than decorators.py. |
I'll start wrapping the other common options and we can discuss alternate names if needed. |
Yes, I agree. Do you think it's best to post a list in this issue or create separate issues for the remaining common option aliases? My preference would be to create separate issues, because I think tasks are less likely to get lost that way and it would make splitting up the workload easier (people can either self-assign, post that they will be working on it, or open a linked PR). Edit: the downside would be if the number of open issues is bothersome to anyone - I suspect that it would be at least a handful |
Up to you whether you want to open a separate issue. If it's just a couple, I was thinking that a comment with a tickbox list will do. You could even edit Leo's original comment on the top to keep track of things without scrolling down. |
Checklist of unwrapped common option aliases
|
@willschlitzer, do you think that the -i ( Here's the list of GMT modules that use
|
Yes, we should. Docstring of any common options should be included in |
I just started working on the alias for the -b common option. However, I find that I am repeating myself a lot in adding these common options (e.g., typing b="binary" and {b} in every module that uses it). I think it could be better to refactor the |
I am closing this issue since all except -: are now listed in COMMON_OPTIONS table. I will open separate issues for adding these options to relevant functions, which will serve as good first issues for new developers. |
Paul compiled this list of aliases and GMT vocabulary. We should include this somewhere in the docs and in the code somewhere to avoid repetition.
GMT Vocabulary for Python Aliases
The idea is to agree on a set of nouns that can serve as the Python aliases for GMT common options as well as commonly used options (such as pens, color).
Common options:
Common themes that could use fixed aliases
The text was updated successfully, but these errors were encountered: