Skip to content
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

Split meca into a standalone module from base_plotting.py #686

Merged
merged 10 commits into from
Jan 26, 2021

Conversation

weiji14
Copy link
Member

@weiji14 weiji14 commented Nov 7, 2020

Description of proposed changes

Begin to split up base_plotting.py into standalone components. Starting with the largest module meca.

New Structure:

pygmt/
  ├── src/ (new folder)
  |        └── meca.py (contains `def meca()` function)
  └── base_plotting.py (contains a line `from pygmt.src.meca import meca`)

The following modules from base_plotting.py may be split up in separate PRs:

  • coast
  • colorbar
  • grdcontour
  • grdimage
  • grdview
  • plot
  • plot3d
  • contour
  • basemap
  • logo
  • image
  • legend
  • text

References:

Addresses #685

Reminders

  • Run make format and make check to make sure the code follows the style guide.
  • Add tests for new features or tests that would have caught the bug that you're fixing.
  • Add new public functions/methods/classes to doc/api/index.rst.
  • Write detailed docstrings for all functions/methods.
  • If adding new functionality, add an example to docstrings or tutorials.

Notes

  • You can write /format in the first line of a comment to lint the code automatically

@weiji14 weiji14 added the maintenance Boring but important stuff for the core devs label Nov 7, 2020
@weiji14 weiji14 changed the title Split up base_plotting.py into standalone modules Split meca into a standalone module from base_plotting.py Nov 7, 2020
@weiji14 weiji14 force-pushed the restructure_base_plotting branch from 613ae9b to bc64ec2 Compare January 24, 2021 20:09
@willschlitzer
Copy link
Contributor

willschlitzer commented Jan 24, 2021

@weiji14 I'm glad you figured out a way to do this! I'm not trying to simplify the work you have done on this, but is this as "simple" as moving a single function to it's own script and adding "from pygmt.src.script import script function? As far as I can tell, that is the case, but I want to check with you before doing work/submitting pull requests for the other functions, especially those that I'm in the process of wrapping.

Also, are we trying to get this completed for PyGMT v0.3? If so, do we have an expected deadline for that? I'm assuming it's before the GMT 6.2 release.

Copy link
Member Author

@weiji14 weiji14 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'm opening this up for review since things kinda work, but need some critical comments on this.

Also, are we trying to get this completed for PyGMT v0.3? If so, do we have an expected deadline for that? I'm assuming it's before the GMT 6.2 release.

Yes, best to release PyGMT v0.3.0 before GMT 6.2 (scheduled for mid-Feb, but traditionally it's always been late). It'll be good to cut a release once we have a good number of new 'features' like inset and such.

arg_str = " ".join([fname, build_arg_string(kwargs)])
lib.call_module("meca", arg_str)
# GMT Supplementary modules
from pygmt.src.meca import meca # pylint: disable=import-outside-toplevel
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this as "simple" as moving a single function to it's own script and adding "from pygmt.src.script import script function? As far as I can tell, that is the case, but I want to check with you before doing work/submitting pull requests for the other functions, especially those that I'm in the process of wrapping.

Yes, this is the key line. It looks simple and works, but:

  1. we would need to write a separate line for each new module (e.g. velo, solar, etc).
  2. I don't really like having the pylint disable=import-outside-toplevel here.

To be honest, there's probably a better way to do this. Any good ideas? Or we can just settle for this for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to have from pygmt.src.meca import meca in pygmt/src/__init__.py, then we only need from pygmt.src import meca, velo, text here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep sure, I'll do that, but it would require changing two files every time we wrap a new module (instead of one right now).

Comment on lines +134 to +135
"""

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that fig.meca doesn't appear to use self._preprocess like the other fig modules, but probably doesn't matter according to #685 (comment)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems OK to me.

@weiji14 weiji14 marked this pull request as ready for review January 24, 2021 21:12
@seisman
Copy link
Member

seisman commented Jan 24, 2021

The final goal is to have one file for one module, including both plotting and non-plotting modules, right? If so, is it better to put these files in a modules directory (I know we already have a modules.py file)?

@weiji14
Copy link
Member Author

weiji14 commented Jan 24, 2021

The final goal is to have one file for one module, including both plotting and non-plotting modules, right?

Not necessarily? We'll need to discuss this more in #685 (or a separate issue), it makes sense for the plotting stuff because there's so many.

If so, is it better to put these files in a modules directory (I know we already have a modules.py file)?

I chose src because GMT and GMT.jl uses src, and so does matplotlib. PyGMT originally had a modules folder in the early days as I mentioned in #685 (comment), but yeah, it's not good having a modules.py and modules folder. Happy to change it to another name though.

@weiji14 weiji14 force-pushed the restructure_base_plotting branch from 8893877 to ef2d002 Compare January 24, 2021 21:47
@weiji14 weiji14 force-pushed the restructure_base_plotting branch from ef2d002 to f8a00ec Compare January 24, 2021 21:49
@weiji14 weiji14 added this to the 0.3.0 milestone Jan 24, 2021
@seisman
Copy link
Member

seisman commented Jan 26, 2021

This PR looks good to me, but I hesitate to merge it into v0.3.0 release. Do we have enough time and human resources to finish all the modules (plotting, and maybe also non-plotting modules) before v0.3.0?

@weiji14
Copy link
Member Author

weiji14 commented Jan 26, 2021

From a user point of view, nothing actually changes. This PR won't close #685, but it will at least enable others to start putting new functions under the src folder instead of base_plotting.py. The other functions (e.g. grdimage, grdview, etc can be moved after v0.3.0) and I should have more time next month once I hand in my thesis to review our growing backlog.

@weiji14 weiji14 merged commit 2345486 into master Jan 26, 2021
@weiji14 weiji14 deleted the restructure_base_plotting branch January 26, 2021 21:13
sixy6e pushed a commit to sixy6e/pygmt that referenced this pull request Dec 21, 2022
…pingTools#686)

Begin to split up base_plotting.py into standalone components.
Starting with the largest module meca.

* Split meca out from base_plotting.py under a pygmt/src folder
* Reduce diff and fix pylint/import errors
* Silence import-outside-toplevel error
* Update __init__.py with meca import
* Re-wrap docstrings to fit 79 characters

Co-authored-by: Dongdong Tian <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Boring but important stuff for the core devs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants