Closed whedon closed 5 years ago
Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @edoddridge, it looks like you're currently assigned as the reviewer for this paper :tada:.
:star: Important :star:
If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿
To fix this do the following two things:
For a list of things I can do to help you, just type:
@whedon commands
Attempting PDF compilation. Reticulating splines etc...
@ChrisBarker-NOAA Just a quick reminder to please do your JOSS review this week. Thanks!
I'm happy to say that I've finished my review of HRDS
and can recommend it for publication. 👍
It is a well-written piece of code that solves a clearly stated problem. 'HRDS' provides a clean interface to mesh together multiple files with different resolutions and create manageable input files for variable resolution geophysical modelling.
While I've opened a number of issues in the code repository, they are all quite minor, and none of them should prevent publication of the paper. With perhaps one exception - it would be a shame to publish the paper before the typos are fixed.
I had very little difficulty obtaining a working version of the code. The dependencies were clearly identified. I encountered only one problem, and the documentation has now been updated to guide users around that issue. The test suite worked straight out of the box.
My only disappointment regarding the testing is the lack of a code coverage tool. The .travis.yml
file contains some commented out lines for using coveralls to assess code coverage. I would recommend (re)implementing a code coverage tool.
The python code is laid out in a clear and logical way. I found it quite easy to work out what each piece of code does.
My biggest concern with this submission is the lack of a real-life worked example. However, @jhill1 has obtained the necessary data and has committed to implementing one soon. Once the data is included, the test suite could be altered to use those datasets instead of the proprietary ones that @jhill1 uses locally.
The overarching documentation is currently limited to the readme. However, given the nature of the software, this is perfectly acceptable. API documentation is contained in docstrings for the various methods and classes. Having extensive docstrings means that Sphinx based documentation could be added in the future without too much extra effort.
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
@ChrisBarker-NOAA Will you be able to complete this JOSS review this week?
Gah I forgot that you aren't working because of the government shutdown. Hm.
https://github.com/EnvModellingGroup/hrds
Overall, this looks like a small, but useful package for raster data processing. But there are some issues with the package structure, tests, and documentation, outlines below.
I recommend that the package be published once the below issues are addressed.
From the README:
"These instructions assume a Debian-based Linux. HDRS should work on other systems, but is currently untested."
There are a lot of users out there that are not running Debian-based Linux -- this project should attempt to provide some guidance for other platforms. UNfotunately, the GDAL stack is pretty ugly to install, so perhaps recommending conda and conda-forge would be a good way to get people rolling in a platform independent way.
I notice that conda is (partially) being used for the CI -- so could full conda instuctions could be provided.
I am testing on OS-X with conda and conda-forge, Python 3.7
In fact, I highly recommend that the project authors make hrds available in conda-forge: https://conda-forge.org/#add_recipe
In the main README, after providing Debian-only install instructions, the primary example is using the firedrake
and thetis
packages -- nifty use-case, but it would be much better, for a more general purpose package to have the primary examples be based only of the core package and its dependencies.
The hrds package is using a standard setuptools / setup.py install. However, there are some issues:
The tests are put in a package that is next to the hrds package, and the setup.py uses setuptools.find_packages to to identify the packages to install. So when run, you get a top-level package called "tests" with the hrds tests in it. This is not good.
Here are some thoughts on where to put tests:
http://pythonchb.github.io/PythonTopics/where_to_put_tests.html
I've provided a PR here that puts the tests internal to the package:
https://github.com/EnvModellingGroup/hrds/pull/18
I also added formatting, etc changes to the setup.py in that PR.
https://github.com/EnvModellingGroup/hrds/issues/21
https://github.com/EnvModellingGroup/hrds/issues/20
PR for fixes to the file finding, and PEP8 compliance fixes is here:
https://github.com/EnvModellingGroup/hrds/pull/24
The HRDS
class appears to be creating temp buffer files that it does not delete:
https://github.com/EnvModellingGroup/hrds/issues/23
NOTE: computer memory is pretty huge these days -- are the buffer files even needed -- maybe only used when the rasters are really big?
The JOSS paper is fine as it goes, but there are a few issues:
There are a few references cited, but nothing in the references section -- are those defined somewhere else?
"a linear distance buffer is created to smoothly blend the two datasets together."
I would like to see some description (and ideally a reference) for this algorithm.
The docs do note that two rasters "are unlikely to agree on the topographic/bathymetric height where they overlap", but there is no mention of (or algorithms for?) accounting for major differences -- different vertical datums, for instance.
The only user docs I could find is the README and docstrings. Some more comprehensive user and reference docs would be good. Also, the docstrings are not complete nor PEP 257 compliant.
Great! Thanks so much for the reviews, @edoddridge and @PythonCHB.
It looks like there are some unchecked check boxes for both reviews currently, and @jhill1 can work on addressing issues that have been brought up. Thanks again everyone.
Just a note that I will have an away message popping up starting tomorrow and I will continue to respond here while I can; once I can't and if this review is still on-going, then another editor will take over.
Thanks both for the reviews (especially whilst furloughed @PythonCHB - much appreciated).
:wave: Hi @jhill1, @edoddridge, @PythonCHB: just a quick note to say that I am happy to answer any questions or help out on the editor side while @kthyng is away.
:wave: Hey @lheagy...
Letting you know, @kthyng
is currently OOO until Sunday, March 31st 2019. :heart:
@jhill1 - I think we're waiting on your responses to @PythonCHB's review at this point.
You are indeed. Swamped with teaching this term, but will get to this ASAP. Thanks for your patience!
I'm going to go ahead and add the "paused" label here. Do ping us when you are ready to re-engage with this submission, @jhill1.
Dear all,
I have fixed the issues pointed out by @PythonCHB
I've summarised each issue and given the fix/response below.
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
Great @jhill1!
@PythonCHB can you look through @jhill1's work to see if you are satisfied to check off the remaining boxes in your review, or if you have follow up comments?
Thanks for addressing my concerns -- this is a more robust package now!
A few issues still:
I have copy edited the README -- PR here:
https://github.com/EnvModellingGroup/hrds/pull/29
Most of that is just copy editing, but a small issue -- in the example in the readme, there is this code:
import sys
sys.path.insert(0,"../../")
from hrds import hrds
messing around with sys.path
like that is not considered good practice these days. As the previous instructions are how to install the package, this is totally unnecessary. And if a user wants to work with the package directly from the source, the recommended way to do that is an "editable install":
pip install -e ./
and then the package will be available with a regular import.
I have removed that code in my PR.
In the thetis
example, there is:
from firedrake import *
from thetis import *
from firedrake import Expression
import *
is highly discouraged these days -- and particularly in example code like this, it's then confusing be3cause you don't know if a name comes from firedrake or thetis. And if you have imported everything from firedrake, you don't need to import Expression.
import *
should be removed -- I have not done this in my PR, as I haven't installed thetis and firedrake to test.
I've added a few copy-edits tot he PR above.
Note that there is a fair bit of overlap between the README and the Sphinx Docs -- (and teh Sphinx docs now need copy editing to match the README). I suggest that you single source these if you can.
gitHub will allow READMEs in RST as well, so you could have one RST page with the intro and all, and include that into your Sphinx docs.
You could also make the README smaller, and link to the more substantial docs -- which you could publish as html via gitHubIO or readthedocs.
It looks like Sphinx auto-doc is not including teh class init docs -- which can be very helpful.
Also, some of those init docstrings (hrds.hrds.HRDS.init, for instance, are not complete -- you should document all the parameters to the init.
from __future__ import print_function
is necessary for py3 only code.
No need to derive from object
in py3 either.
I see this:
def set_mask(self, mask):
"""
Set a mask to use. Not yet implemented.
"""
self.mask = mask
This is why Python has "properties" -- there is not need to write do-nothing getters and setters.
https://uwpce-pythoncert.github.io/PythonCertDevel/modules/Properties.html?highlight=properties
The References section is blank -- but there is at least one reference in the paper -- am I missing something?
I'd still like to see a more description the buffering algorithm -- linear interpolation does not need defining, but exactly how one interpolates between two different resolutions of rasters in the buffer zone is not obvious.
None of these issues are fatal -- congrats! You've made a nice contribution to the community.
Thanks so much @PythonCHB!
@jhill1 Can you address these comments soon?
Thanks @PythonCHB !
The pull request has been merged (thanks for that!).
Documents: I've pulled over the changes in the README to the Sphinx docs and will have a think about how to make the best of them. I have a summer student this year who will be using this code, so we'll see how they get on and then I might ask them to rationalise the docs along the lines proposed.
I've removed all the import *
from docs and code examples and the leftover Python 2 code. I haven't removed the set_mask yet (as a reminder for me to implement this) - the code will have to do more than set the self.mask variable (e.g. regenerate buffers).
Paper: I've added a figure to explain the buffer which will hopefully help The references are added automatically by JOSS when the PDF is created.
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
Great work @jhill1 it looks like you have addressed all of @PythonCHB's comments. There is one unchecked box, but the pdf does indeed now have references included and they have doi's when appropriate.
I am going through my own checks now.
@whedon check references
Attempting to check references...
OK DOIs
- 10.1016/j.renene.2017.09.058 is OK
- 10.1016/j.renene.2014.11.079 is OK
MISSING DOIs
- None
INVALID DOIs
- None
@jhill1 your citation of Martin-Short2015 shouldn't have parentheses so that it is inline as it is part of the sentence as written.
@jhill1 After that fix, please make a Zenodo archive, and report the DOI in this thread.
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
Hi @kthyng. Thanks for editing this submission - it's been fun. Zenodo DOI: 10.5281/zenodo.2691685
@jhill1 agreed!
Ok I just looked up your submission to Zenodo and the metadata includes @PythonCHB which is nice but not correct — this often happens. Can you edit the metadata so that it matches your paper submission? In particular you want the author list to match, and the title to match.
Fixed. Will add the .json to fix that properly at some point. Thanks.
Great!
@whedon set 10.5281/zenodo.2691685 as archive
OK. 10.5281/zenodo.2691685 is the archive.
@whedon set <v0.1.2> as version
OK. <v0.1.2> is the version.
Submitting author: @jhill1 (Jon Hill) Repository: https://github.com/EnvModellingGroup/hdrs Version: 0.1.2 Editor: @kthyng Reviewer: @edoddridge, @PythonCHB Archive: 10.5281/zenodo.2691685
Status
Status badge code:
Reviewers and authors:
Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)
Reviewer instructions & questions
@edoddridge & @ PythonCHB, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:
The reviewer guidelines are available here: https://joss.theoj.org/about#reviewer_guidelines. Any questions/concerns please let @kthyng know.
✨ Please try and complete your review in the next two weeks ✨
Review checklist for @edoddridge
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
paper.md
file include a list of authors with their affiliations?Review checklist for @PythonCHB
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
paper.md
file include a list of authors with their affiliations?