pyrolite Submission

[morganjwilliams]

Submitting Author: Morgan Williams (@morganjwilliams)
All current maintainers: Morgan Williams (@morganjwilliams)
Package Name: pyrolite
One-Line Description of Package: A set of tools for getting the most from your geochemical data.
Repository Link: https://github.com/morganjwilliams/pyrolite
Version submitted: 0.2.5
Editor: @lwasser
Reviewer 1: @rbeucher
Reviewer 2: @charlesll
Archive:
JOSS DOI:
Version accepted: v 0.2.7
Date accepted (month/day/year): 06/04/2020

---

Description

• Include a brief paragraph describing what your package does:

pyrolite provides tools for munging, transforming and visualising geochemical data from common tabular formats. It enables you to recalculate and rescale whole-rock and mineral compositions, perform compositional statistics and create appropriate visualisations and also includes numerous specific utilities (e.g. a geological timescale).

Scope

• Please indicate which category or categories this package falls under:

  • Data retrieval
  • Data extraction
  • Data munging
  • Data deposition
  • Reproducibility
  • Geospatial
  • Education
  • Data visualization*

• Explain how the and why the package falls under these categories (briefly, 1-2 sentences):

pyrolite leverages Pandas to enable import, munging and transformation of geochemical data from standard tabular formats, and matplotlib to facilitate common (and some less common) geochemical visualisations. One of the principal project aims is assisting to improve the reproducibility of geochemical research (especially for data-processing steps which often are overlooked or undocumented).

With regards to education, pyrolite is well suited to being incorporated into university-level geochemistry and petrology classes which wish to teach a little Python. The documentation is continually evolving, and more examples and tutorials will gradually be added. It isn't a principal aim of the project, however.

• Who is the target audience and what are scientific applications of this package?

pyrolite is targeted towards geochemists and geoscientists who use geochemical data (chemistry, mineralogy and relevant properties), especially those using lithogeochemistry. pyrolite has been developed principally to enable more reproducible data import, munging, transformation and visualization for geochemical data. In addition to this, pyrolite:

• Encourages better practices throughout these processes, including the use of compositional statistics (i.e. log-transforms).

• Implements some common geochemical models and methods to make these easily accessible and reusable (e.g. lattice strain models, orthogonal polynomial decomposition of Rare Earth Element patterns - 'lambdas').

• Contains a small database of rock forming minerals for normative calculations and looking up mineral formulae.

Extensions beyond the core package are also being developed for specific applications or interfaces (e.g. to alphaMELTS).

• Are there other Python packages that accomplish the same thing? If so, how does yours differ?

There is at least one other Python package which has some minor overlap for visualisations (GeoPyTool, which has a GUI-focused interface), but generally there are few open source Python packages for geochemistry (especially on PyPI). pyrolite provides some broader functionality (for both plotting and handling geochemistry) and is designed to be used from an editor or terminal and encourage geoscientists to further develop transferable Python skills. Where practical, the APIs for the tools on which it is built are exposed (e.g. pandas, matplotlib and sklearn).

• If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted:

#17

Technical checks

For details about the pyOpenSci packaging requirements, see our packaging guide. Confirm each of the following by checking the box. This package:

• does not violate the Terms of Service of any service it interacts with.
• has an OSI approved license
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration, such as Travis CI, AppVeyor, CircleCI, and/or others.

Publication options

• Do you wish to automatically submit to the Journal of Open Source Software? If so:

JOSS Checks

• The package has an obvious research application according to JOSS's definition in their submission requirements. Be aware that completing the pyOpenSci review process does not guarantee acceptance to JOSS. Be sure to read their submission requirements (linked above) if you are interested in submitting to JOSS.
• The package is not a "minor utility" as defined by JOSS's submission requirements: "Minor ‘utility’ packages, including ‘thin’ API clients, are not acceptable." pyOpenSci welcomes these packages under "Data Retrieval", but JOSS has slightly different criteria.
• The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
• The package is deposited in a long-term repository with the DOI: 10.5281/zenodo.2545106

Note: Do not submit your package separately to JOSS

Are you OK with Reviewers Submitting Issues and/or pull requests to your Repo Directly?

This option will allow reviewers to open smaller issues that can then be linked to PR's rather than submitting a more dense text based review. It will also allow you to demonstrate addressing the issue via PR links.

• Yes I am OK with reviewers submitting requested changes as issues to my repo. Reviewers will then link to the issues in their submitted review.

Code of conduct

• I agree to abide by pyOpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

P.S. Have feedback/comments about our review process? Leave a comment here

Editor and Review Templates

Editor and review templates can be found here

[lwasser]

Editor's Template

Editor checks:

• Fit: The package meets criteria for fit and overlap.
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has an OSI accepted license
• Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

The license is a variant on BSD / MIT -- Chat with RO about this...

Reviewers:
Due date: Thursday April, 30th

hi @morganjwilliams just a note that i have this review on my radar and will get going with finding an editor and reviewers shortly. Everything has slowed down a lot in the past month with the current events. Thank you for your patience!

[morganjwilliams]

Thanks @lwasser, I hope you're faring well! I've asked one potential reviewer, and will tag them here shortly if they're interested.

[morganjwilliams]

Hi @lwasser, just a quick update - @charlesll has indicated he's interesting in reviewing this.

[lwasser]

oh wonderful! thank ou @morganjwilliams let me put a ping out on twitter for a second reviewer while we wait for @charlesll to respond! thank you

[rbeucher]

Happy to help if you are still looking for a reviewer

[charlesll]

Hi, I can review this package. Let me know what is the protocol. Thanks!

[lwasser]

oh awesome!! thank you @rbeucher and @charlesll !! i'll add you as reviewers. so here is how it goes

The review guidelines can be found here. read them over. I need to update that document to contain more recieve pyopensci reviews. when we started we only had ropensci as a model.

When you have completed your review - use the review template so submit your review.

we typically ask for a 3 week turn around on reviews. So if it is possible to complete your review by Thursday April, 30th that would be perfect.

At pyopensci we offer the option of including issues that you open as a part of your review that are then addressed through the review. @morganjwilliams has opted to allow this so feel free to submit issues (or pr's) as need be to address things.

Also he has opted to be considered for JOSS. So when we get to that step, we will ask you to have a look at the paper and ensure the package meets the JOSS requirements. we can discuss that as we are further along.

Thank you both for being willing to review this submission. Please get in touch at any point if you have questions OR suggestions. We are still refining our process so we have been tweaking things in each review.

[rbeucher]

Thanks @lwasser ,

[rbeucher]

Hi, please find my review below:

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README

rbeucher: This is clearly written in the readthedocs documentation. Please copy and paste to the README

• Installation instructions: for the development version of package and any non-standard dependencies in README
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all user-facing functions
• Examples for all user-facing functions
• Community guidelines including contribution guidelines in the README or CONTRIBUTING.
• Metadata including author(s), author e-mail(s), a url, and any other relevant metadata e.g., in a setup.py file or elsewhere.

Readme requirements
The package meets the readme requirements below:

• Package has a README.md file in the root directory.

The README should include, from top to bottom:

• The package name
• Badges for continuous integration and test coverage, the badge for pyOpenSci peer-review once it has started (see below), a repostatus.org badge, and any other badges. If the README has many more badges, you might want to consider using a table for badges, see this example, that one and that one. Such a table should be more wide than high.
• Short description of goals of package, with descriptive links to all vignettes (rendered, i.e. readable, cf the documentation website section) unless the package is small and there’s only one vignette repeating the README.

rbeucher: Again, this can just be copied from the documentation.

• Installation instructions
• Any additional setup required (authentication tokens, etc)
• Brief demonstration usage

rbeucher: The package as a large range of application, I am not sure how this can be done. Maybe a couple of examples.

• Direction to more detailed documentation (e.g. your documentation files or website).
• If applicable, how the package compares to other similar packages and/or how it relates to other packages

rbeucher: There are probably many packages available on Github that do similar things. Pyrolite as broader applications.

• Citation information

Functionality

• Installation: Installation succeeds as documented.

• Functionality: Any functional claims of the software been confirmed.

• Performance: Any performance claims of the software been confirmed.

• Automated tests: Tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
  rbeucher: 1 test failed: test/plot/plot_spider.py:32

• Continuous Integration: Has continuous integration, such as Travis CI, AppVeyor, CircleCI, and/or others.

• Packaging guidelines: The package conforms to the pyOpenSci packaging guidelines.

For packages co-submitting to JOSS

• The package has an obvious research application according to JOSS's definition in their submission requirements.

Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.

The package contains a paper.md matching JOSS's requirements with:

• A short summary describing the high-level functionality of the software
• Authors: A list of authors with their affiliations
• A statement of need clearly stating problems the software is designed to solve and its target audience.
• References: with DOIs for all those that have one (e.g. papers, datasets, software).

Final approval (post-review)

• The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 4

Review Comments

Pyrolite is without a doubt a very useful package and I will certainly recommend it to my students and colleague.
I have been impressed by the quality of the package. There has been a lot of work in making sure that the functionalities are well documented, both in the docstrings and on readthedocs. The examples provided covers an impressive range of very useful applications. I only had a quick look at the code but it definitely follows some very good practices and I will likely borrow some ideas.

The package is likely to be difficult to use for python beginners but I think that the author has striken the right balance between flexibility and usage. The pandas and matplolib libraries have been leveraged in a way that will provide future-proof development of the code. As a developer myself, I really appreciate the effort and the quality of the work delivered.

There is an extensive range of tests. All of them except 1 have passed on my local machine.
I have spent some time playing with the Jupyter notebook provided on readthedocs.
Some markdown could be added to the notebooks but users can largely figure out what is going on thanks to the docstrings available for each function.
There is a lot of very interesting functionalities (Unit scaling, Convert to oxyde, reference models, composition etc.).

A few Jupyter notebooks break because of a pandas deprecation. This has already been flagged in the issue tracker #31. This must be fixed before accepting the package.

I have also found a few problems due to some data files missing in the data folder. The files were not listed in the MANIFEST.in. I believe this has been fixed in the dev branch and will have to be merged in the version submitted to PyOpenSci.

I would encourage the author to highlight the package as an excellent ressource for teaching in the README.

Having the option to run the examples with Binder is great. However, I found the binders very long to start and I give up at some point. I have not looked at the binder set up but it would be good to improve that if possible.

I hope you will find that review useful.

Romain Beucher

[morganjwilliams]

@rbeucher thanks for your effort in this review and highlighting a few issues! I'll put out a new release shortly (it will be 0.2.6, incorporating changes currently listed in the changelog 'Development' section) with the majority of these issues addressed and an updated README, and make a note here when it's available.

I've struggled in getting binder to boot up quickly, which is partly due to the relatively heavy dependencies (numpy, pandas, matplotlib, scipy, sklearn), and partly due to the fact that it's likely updated more often than people access the binder links (hence the docker image is rebuilt on-access). Happy to incorporate suggestions to make this easier to work with if anyone has ideas on this front.