The PyGMT folks had their first informal meeting on 27 Jun 2020 (UTC 19:30), mainly to talk about the Scipy 2020 sprint, but we also touched on other long term plans. These are the meeting minutes:
Participants: Dongdong, Leo, Liam, Wei Ji
- Scipy 2020 Sprints
- Conda-forge weekly GMT builds
- Remote Online Sessions for Emerging Seismologists (ROSES) module
- PyGMT as a high-level Pythonic API for plotting geographic data
- Postdoc from NSF funding
- Prepare for multiple ability levels
- Beginner only for Scipy 2020
- Gallery examples - Make it easy for folks to contribute
- grdview/grdimage/grdtrack example
- Open issues with tag ‘Scipy 2020’ for people to work on.
- Bugs to be fixed prior to sprint
- Be aware of GMT 6.1.0 compatibility
- Pin to GMT < 6.1.0 so people don’t upgrade? Or tell users to conda install gmt=6.0
- API changes fixed in GMT master branches, mostly ok in PyGMT but need to confirm
- GMT and PyGMT advance in sync, e.g. GMT 6.0 = PyGMT v0.1.x, GMT 6.1 = PyGMT v0.2.x
- Scipy sprints very informal, at least in person (the 2017 one), people might just show up? Not sure about online, be on toes.
- Find a PR that was merged, and use as an example to newcomers on what to expect with the review process
- Manage expectations on people’s git/github experience
- Give Liam access to label stuff on PyGMT repo and as forum moderator
- Managing discussions during sprint
- Use GMT forum as discussion board
- Zoom/Slack/Gitter chat for informal conversation
- Github for bugs or how to implement something new e.g. a wrapper
Conda weekly GMT build
- Ensure changes in GMT don’t break PyGMT, also good for other GMT/GMT.jl/GMTmex users
- Also nice to put in try-gmt repo at https://github.com/GenericMappingTools/try-gmt, have stable GMT 6.0, and also unstable GMT master
- Filipe not on board of maintenance, very busy person
- Docker image? Maybe better to compile on conda CI as compilers there support conda-forge ecosystem better
- Could be a weekly CI job that compiles GMT. Not a problem if it only happens once a week and takes a long time.
- Linux/macOS priority. Windows, if requested
- Early August
- Slack organization with 173 members, massive Zoom meetings
- Obspy workshop on Jupyter notebooks with breakout sessions
- Good opportunity for visibility
- Get some material from FOSS4G 2019 at https://github.com/GenericMappingTools/foss4g2019oceania
- Tie in ObsPy with PyGMT, get a waveform/station map, and start plotting that, look at Slack where they have modules on everything? Students like it when we tie topics together
- Mention about GMT modules that are not wrapped yet in PyGMT, for those seismic students that have used GMT in grad school, access using lib.call_module?
- Demand is high, 500 students in one cohort?
- Make good use of Teaching Assistants? 1 hour lecture + 1 hour lab. Have someone keeping an eye on the chat
- Specific stuff, e.g. new Python users, people not familiar with grids or projection systems
PyGMT as a high-level Pythonic API for plotting geographic data
- Should we keep functions/Method names exactly the same in GMT as PyGMT?
- Things grew to be different flags in one function, e.g. -B flag in GMT is large, instead of having more discrete functions that do one thing and one thing only
- E.g. Coast can write coastline to files, not just plot coastlines
- E.g. blockmode/blockmean can output table and grids
- Maybe try not to be just GMT in Python, don’t be restricted by the namespace
- Emulate good parts of Matplotlib/GMT, but we can do things differently, long term stuff
- Name-wise, do we cater to users coming from GMT, or from Matplotlib, or from Cartopy?
- What is the geoscience plotting library that we want to be?
- Object orientated projection structure of Cartopy, see PR on Projection classes at https://github.com/GenericMappingTools/pygmt/pull/379
- Interactivity in PyGMT, e.g. zooming into plots. NASA worldwind example Leo did a while ago broken quite often
- GMT was designed for print, publication figures
- Use analogy of Adobe Illustrator, layered on layered
- Multiple levels of API? Matplolib has that, object orientated stuff and pyplot. Want to avoid that, don’t build a lot of stuff we don’t want to support later
- Be more strategic on what we can do in Python, could be more than GMT or Matplotlib
- Lib.call_module -> can put in data easily, but pulling data out using Tempfiles is tricky
- Look at gmtmex/GMT.jl which handles data IO transparently
- GMT C API - a deep rabbit hole
- Postdoctoral position in GMT software development
- Up to 3 years funding?
- Is she/he going to work on GMT/PyGMT? What is her/his allocation of time between the different projects
- Quite flexible, but help work on base GMT, and if know python, then could help out with the Python side
- Help review entire GMT code base, even Joaquim with 15 years on GMT and he doesn’t know everything
- Work with Paul to refactor/restructure the API, somehow