Fetching contributors…
Cannot retrieve contributors at this time
210 lines (119 sloc) 13.5 KB


Ways to contribute

As an open-source, community project, we welcome improvements and feedback! There are two main ways to contribute to the PmagPy project.

  1. If you want to report a bug or request a new feature, you can click here to create a Github issue. If you are reporting a bug, please provide as much detail as possible about how you discovered the bug. For a full explanation of how to create a new issue, and what information to include, see Github documentation.

  2. If you want to add a new feature yourself or fix a bug yourself, that's great too. The process for adding a feature looks like this: fork the PmagPy repository, create a branch for your feature or bugfix, make some changes, and then submit a pull request. Don't worry if you don't know how to do all of those steps! If you aren't familiar with git, Github, or the details of this process, you will find this short tutorial helpful. If you're still stuck after that but want to contribute, you can create a Github issue and we will help get you sorted. Depending on what kind of contribution you are making, you may also want to add some tests. See our testing README for details on making and running PmagPy tests.

If you will be making significant contributions via git, we have some additional guidelines for good git protocols.

Style guidelines

Good code must be readable. To that end, we request that contributors try to write code that can be understood by others! One way to do this is by adhering to reasonable style guidelines. For more information about standard Python style guidelines, see PEP 8.

Testing guidelines

For information about writing and running tests, see the testing README.

Directory structure

Next we have a breakdown of how the PmagPy repository is structured. In some cases, we have included relevant Jupyter notebooks so that you can get an interactive demonstration of how some these pieces of code work.

Key directories


The pmagpy directory contains all the low-level functionality that the PmagPy project is built on. and contain many functions that can be used in Jupyter notebooks or for building up more complex programs and GUIs. Other important modules in the pmagpy directory:

  • a plotting library --
  • a utility for building up MagIC contributions --
  • modules for interfacing with the data models (,, and, as well as a full backup of the 2.5 and 3.0. data model (in the data_model subdirectory).

To see a notebook with examples of how to use and, see the Example_PmagPy_Notebook.ipynb

To actually run that notebook you will need to download it from the 2016_Tauxe-et-al_PmagPy_notebooks repository:

  • Go into your command line.
  • Change directories into a directory where you keep projects.

git clone

cd 2016_Tauxe-et-al_PmagPy_Notebooks

jupyter notebook

  • A browser window will open automatically. Click Example_PmagPy_Notebook.ipynb

  • For more examples of how to use, try Additional_PmagPy_Examples.ipynb as well (located in the same directory as the previous notebook).

To see example notebooks for building and examing a MagIC contribution, see Intro to MagIC DataFrames.ipynb and Intro to MagIC Contributions.ipynb. To run those notebooks, follow the instructions for running PmagPy notebooks.


The SPD directory contains a program to calculate statistics using Greig Paterson's standard paleointensity definitions.


The programs directory contains executable programs that are installed as part of the pmagpy-cli package and can be run on the command-line.

To see a notebook with examples of how to run most of the command-line programs, see the _PmagPy.ipynb. Also see _PmagPy_3.0.ipynb.

To actually run those notebooks, you will need to follow these directions.


The dialogs directory contains GUI components that are used to build the graphical elements of the PmagPy GUIs.


data_files contains example files used in testing and in Cookbook examples.


notebooks is a subdirectory of data_files and contains a number of example Jupyter notebooks that demonstrate PmagPy functionality.


pmag_env is a module that sets the backend for plotting as either TKAgg (for non-wxPython programs) or WXAgg (for wxPython programs).


locator is a module that finds the directory where PmagPy is installed. Please use caution in modifying this module! You can break a lot of things.

Less key directories

  • help_files contains html help that is used in the GUIs.

  • setup_scripts contains scripts that are used in created standalone releases of the GUIs for Mac, Windows, and Linux.

  • bin contains some scripts that are used in creating the Anaconda part of a pip release.

  • build, dist, pmagpy.egg_info and pmagpy_cli.egg_info are not in the main Github repo, however they may be created automatically when making a pip release. You should not need to interact directly with any of them.

  • is an executable that allows users who installed PmagPy pre-pip to uninstall it completely. This prevents possible conflicts between old and new versions of PmagPy.

Here is a visual representation of the directory structure:

├── bin
├── build
├── data_files
│   └── notebooks
├── dialogs
│   └── help_files
├── dist
├── help_files
├── locator
├── pmag_env
├── pmagpy
│   ├── data_model
│   └── mapping
├── pmagpy.egg-info
├── pmagpy_cli.egg-info
├── pmagpy_tests
├── programs
│   ├── deprecated
├── setup_scripts

Running notebooks

  • If you have installed PmagPy using pip (standard), you will need to move your data_files to an accessible location. To do that, you will use the command-line program

    • You will need to go into your command line to run this program. You can run it from the directory in which you want to place the PmagPy data_files (perhaps your Desktop), using this command: -d . # ("." represents your current directory)

    • Alternatively, you can run it from any directory in your command line using the full destination directory name: -d ~/Desktop

    • If you have done the "developer install" of PmagPy, you can simply navigate to your PmagPy directory.
  • Once you have located or moved the data_files, navigate to the data_files directory on your command line. Run the command:

    jupyter notebook

  • Click on the notebooks directory, then click on the notebook you want to open. A window will pop up in your default browser with the notebook's contents. You can then run the notebook cells.

Git protocols

For an open source project with multiple contributors, it is especially important for changes to be well and clearly documented. Your reasoning for a certain change may be clear to you, but might need a little extra explanation for someone else. Here are some basic guidelines to keep in mind.

  • Commits should have descriptive names that briefly explain what was done and why. "Edited" is a bad commit name!

  • If your commit directly fixes Github issue 100, it is useful to include "Fixes #100" in the text of the commit. This syntax both closes the issue and links the issue to the commit for future reference. However, commit names should always include more detail that just “Fixes #100” - additional context means that the commit message can stand alone.

  • Commits should deal with one concern at a time — spanning multiple files is fine, but commits with many unrelated changes are confusing and should be broken up. This makes it easier for someone else to understand what happened, and if something broke in a particular commit it is easier to track it down if the changes are more isolated.

  • If you are making a large change that will take multiple commits to implement, it is best to start a feature/fix branch. Once the feature or fix is done, the changes can be merged into master without breaking core functionality in the meantime.

  • Here is a nifty article with some fun Github keyboard shortcuts to let you navigate around Github quickly and easily.

If you are left with any questions about git and Github best practices, go ahead and make a new Github issue and we will try to get it worked out!

Compile and Release Guide

We try to make new releases of PmagPy several times per year.

A new release includes: updated pip packages (pmagpy & pmagpy-cli), and updated standalone GUIs (for Windows, Mac, and Linux).

  • Make sure you are set up with PyPI. You must have a PyPI account and be added as an Owner or Maintainer of pmagpy and pmagpy-cli. You will need to install twine using pip install twine. You will also need to create a .pypirc file in your home directory (see sample .pypirc file).

  • Make sure all tests are passing and all new features are working.

  • These are the steps to make a new pip release for pmagpy and pmagpy-cli:

    • First, increment the version number pmagpy/ PYPI will reject a duplicate version number, so you need to update each time. Release numbers are in the form of MAJOR.MINOR.PATCH, and each release number should be higher than the one before it. More on semantic versioning can be found here. The pip release and the standalones should all use the same release number!

    • From the PmagPy directory, use the following command to build a new distribution of pmagpy, upload it to PYPI, and upgrade locally:

    rm -rf build dist && python sdist bdist_wheel && twine upload dist/*

    • To install that new release: pip install pmagpy --upgrade --no-deps

    • To make a test release, use a slightly different command from the PmagPy directory, which will: build a new distribution of pmagpy, upload it to the test site (will not overwrite the version people can download), and upgrade locally:

    rm -rf build dist && python sdist bdist_wheel && twine upload dist/* -r testpypi

    • To install the test release: pip install -i pmagpy --upgrade --no-deps

    • To build pmagpy-cli, you can use the same two commands above, but replacing "" with "".

    • A few notes on the whole thing: first of all, testing the pip install locally doesn't work very well (i.e., python install or python test), because it doesn’t deal correctly with the required data files. Whenever testing a new pip distribution, it is best to upload to test_PYPI instead, even though it takes a minute or so to do. Second, we are using twine for uploading to real PYPI but not to upload to test PYPI. Using twine is recommended because it transfers the package data in a more secure way, but it doesn't currently work with test_PYPI.

    • This article has some more good information about uploading to PYPI, etc.: clearest but slightly out of date, official documentation, how to use testpypi.

  • Create standalone executables. The process is different for each platform, and details are in the standalones README.


PmagPy-specific resources

Detailed information about installing and running all of the PmagPy programs

The larger world of MagIC and paleomagnetism

The MagIC database

Lisa Tauxe's Essentials of Paleomagnetism

Programming resources

Learn Python here! These tutorials are in a sandbox environment, so you don't even need to install Python first.

Another place to learn Python.

Learn wxPython, which is the basis of our GUIs here

Learn more about git here.