Closed MetinSa closed 5 months ago
Hi there! Thank you for submitting your package for pyOpenSci review. Below are the basic checks that your package needs to pass to begin our review. If some of these are missing, we will ask you to work on them before the review process begins.
Please check our Python packaging guide for more information on the elements below.
import package
.README.md
file with clear explanation of what the package does, instructions on how to install it, and a link to development instructions.CONTRIBUTING.md
file that details how to install and contribute to the package.CODE_OF_CONDUCT.md
file.YAML
header of the issue (located at the top of the issue template).Hello there and welcome to the pyOpenSci universe (apologies for the bad pun 😂🌟)! We're happy you're here. I've done a quick overview of the zodipy
package, and you are in great shape! There are a few things we will need before we start with your review:
CODE_OF_CONDUCT.md
to the root of your repository. For more information, pyOpenSci's packaging guide has some examples and information on CoC files.CONTRIBUTING.md
to the root of your repository. For more information, pyOpenSci's packaging guide has some templates and information on CONTRIBUTING files.Let us know when you've made these updates. I'll also use this message to introduce your editor-- @dhomeier will be helping you all through the review process 🎉 Thanks for taking on this role Derek!
Hi! :wave:
I have now added a CODE_OF_CONDUCT.md
and a CONTRIBUTING.md
to the repository aswell as having filled out the survey. I also added @hermda02 as a maintainer of the project.
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
The package includes all the following forms of documentation:
pyproject.toml
file or elsewhere.Readme file requirements The package meets the readme requirements below:
The README should include, from top to bottom:
NOTE: If the README has many more badges, you might want to consider using a table for badges: see this example. Such a table should be more wide than high. (Note that the a badge for pyOpenSci peer-review will be provided upon acceptance.)
Reviewers are encouraged to submit suggestions (or pull requests) that will improve the usability of the package as a whole. Package structure should follow general community best-practices. In general please consider whether:
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:
Estimated hours spent reviewing: 4
~I skipped the JOSS section because I don't see a paper.md
and so assume this package isn't asking for JOSS listing also.~
2024-04-16: I updated the JOSS section but left References unchecked because paper.md
has empty section for that part.
This package is already in Astropy's pre-APE 22 legacy listing over at https://www.astropy.org/affiliated/legacy.html via https://github.com/astropy/astropy.github.com/pull/495 .
I'm sorry, I had forgotten about the JOSS section but would very much like a JOSS listing. I will start working on a paper.md
.
@MetinSa , thanks for going through Astropy's old process and then again with this one. Your patience and dedication is greatly appreciated.
Apologies for the delay. I have now added a paper directory containing the paper.md
file for the JOSS listing.
How long does a typical JOSS submission and review process take in this context?
FYI -- I have updated the checkboxes for JOSS at https://github.com/pyOpenSci/software-submission/issues/161 for my part of the review.
p.s. I never submitted anything to JOSS before so I cannot answer the questions about JOSS timeline. Hopefully others can. Thanks for your patience!
hi 👋 i can help here. it's normally quick IF the submittor makes it clear when the package is submitted that:
I've seen this go wrong when there is confusion regarding the fast track part and then things take a bit longer. but otherwise it should be a few weeks if the JOSS editor follows the process and the pyOS editor kind of keeps an eye on things ! i hope that helps.
Thanks!
Thank you for the updates and apologies for the delays in reviewing; getting reviewers with the topical expertise for Astropy into the system is a prolonged process!
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
The package includes all the following forms of documentation:
pyproject.toml
file or elsewhere.Readme file requirements The package meets the readme requirements below:
The README should include, from top to bottom:
NOTE: If the README has many more badges, you might want to consider using a table for badges: see this example. Such a table should be more wide than high. (Note that the a badge for pyOpenSci peer-review will be provided upon acceptance.)
Reviewers are encouraged to submit suggestions (or pull requests) that will improve the usability of the package as a whole. Package structure should follow general community best-practices. In general please consider whether:
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:
Estimated hours spent reviewing: 2 (includes original review as an Astropy affiliated package)
Mostly reproduced from my Astropy affiliated package review.
ZodiPy looks like a very healthy package. Here are some spots where there is room for improvement.
Methods do not support Numpy broadcasting for arbitrary input shapes. For example, it appears that obs_time must be scalar. For another, this line in get_obs_and_earth_positions discards the shape of the input arguments:
return obs_position.reshape(3, 1, 1).value, earth_position.reshape(3, 1, 1).value
ZodiPy supports parallelism using Python multiprocessing, but it creates its own process pool and discards it when it is done. It would be nice if it supported the pool being passed by the user so that the cost of spawning child Python interpreters is not borne repeatedly. Also there are situations where it is necessary to use a custom Pool subclass (e.g. billiard, https://pypi.org/project/billiard/).
GPL-3.0-only
or GPL-3.0-or-later
.project.urls
section in pyproject.toml). For project URL names that PyPI displays prominently with icons, see https://github.com/pypi/warehouse/blob/main/warehouse/templates/packaging/detail.html.The project uses ruff for code formatting, but it is only run on the module itself. Ruff would make changes to the Python modules in the tests directory. Please consider running ruff on the entire project, including the tests.
Thank you for the review @lpsinger!
I have made the following changes after going through the review:
pyproject.toml
file now includes urls to the documentation and repository (https://github.com/Cosmoglobe/zodipy/commit/7ae9119c06088a86e7b9c9143c0934ca25c3908b)Additionally, I have opened several issues (see the mentions above) to address your suggestions for improvement and to better integrate ZodiPy with Astropy. I will start working on these as soon as I find the time.
Thank you for your careful and helpful reviews @pllim and @lpsinger, and for your quick reply @MetinSa! I'll second the recommendation to include the tests in code style checks, as in a similar attempt in astropy/astropy#16158 we have discovered a number of tests that were not testing exactly the intended functionality. That should not block acceptance of your package at this time, though.
@pllim I only found one reference, PyEphem, without a DOI in paper.bib
, but it does not seem to have one in the ASCL entry either – do you think it should have one?
I'm not familiar with what JOSS wants in its References section. If it's ok to leave empty, then I'm fine with that. All in all, I don't think it should block acceptance.
Thank you for the review @lpsinger!
I have made the following changes after going through the review:
You're very welcome! Sorry it took me so long to post it.
I've checked off all of the remaining items in the review template.
I'm not familiar with what JOSS wants in its References section. If it's ok to leave empty, then I'm fine with that. All in all, I don't think it should block acceptance.
The references are all there in the paper.bib file – I was assuming JOSS would accept a standard LaTeX setup, but not actually sure how it handles it with a .md main text – never mind, this is exactly as prescribed in the Author guide.
I'm not familiar with what JOSS wants in its References section. If it's ok to leave empty, then I'm fine with that. All in all, I don't think it should block acceptance.
The reference section look all right in this paper draft compiled with the JOSS gh-action.
Yes, I've checked that off and the reviewers have already checked their final approval. Just waiting if there is a short term fix for the conda-forge build, but since that is really a healpy issue, it should not block either.
Ah, sorry I misunderstood how JOSS formatting works. I will check off the References box now (oh nvm, looks like Derek did it for me, thanks!). Thanks for the clarifications!
I think we better figure out how to list this on our webpage soon? 😬
cc @eteq @lwasser
Great, with conda-forge succeeding for Linux and macOS, this should be ready for JOSS submission.
🎉 zodipy has been approved by pyOpenSci! Thank you @MetinSa for submitting ZodiPy and many thanks to @pllim and @lpsinger for reviewing this package! 😸
There are a few things left to do to wrap up this submission:
[![pyOpenSci](https://tinyurl.com/y22nb8up)](https://github.com/pyOpenSci/software-review/issues/issue-number)
.It looks like you would like to submit this package to JOSS. Here are the next steps:
🎉 Congratulations! You are now published with both JOSS and pyOpenSci! 🎉
Please complete the final steps to wrap up this review. Editor, please do the following:
6/pyOS-approved6 🚀🚀🚀
.6/pyOS-approved
label). Once accepted add the label 9/joss-approved
to the issue. Skip this check if the package is not submitted to JOSS.If you have any feedback for us about the review process please feel free to share it here. We are always looking to improve our process and documentation in the peer-review-guide.
🎉🎉 I have completed the Zenodo and pyOpenSci peer-review steps(https://github.com/Cosmoglobe/zodipy/commit/2c03c586ae0b4fe7ab06d12d2115c215dbdf9b5d, https://github.com/Cosmoglobe/zodipy/commit/b5d0031fe7fc3d6c05c5aec942c6a067b86c5cdd) and will fill out the post-review survey tomorrow (pre-review survey is filled out already). Edit: post-review survey is filled out and I have submitted to JOSS referencing this thread and the Zenodo DOI.
Thank you to everyone here for the reviews and all the help:)
JOSS paper is approved and published https://joss.theoj.org/papers/10.21105/joss.06648!
Congratulations again @MetinSa to your successful publication with pyOpenSci and JOSS! I'd like to take the opportunity to invite you and your maintainer team to write a blog post (totally optional) on your package for us to promote your work! If you are interested - here are a few examples of other blog posts:
pandera rdata SunPy (external blog)
and here is a markdown example that you could use as a guide when creating your post.
It can even be a tutorial-like post that highlights what your package does and how to use it. Then we can share it with people to get the word out about your package.
If you are too busy for this, no worries. But if you have time - we'd love to spread the word about your package!
Thank you @dhomeier and a big thanks to everyone else involved in the review. I will try to write up a blog post sometime in the future when I find the time.
Closing the issue as completed as ZodiPy is now listed on https://www.pyopensci.org/python-packages.html
Feel free to follow up with a blog post whenever convenient; also if you wish to join the pyOpenSci Slack space @dncnwtts or @hermda02, you are welcome to send us an email address to be signed up with.
Submitting Author: Metin San (@metinsa) All current maintainers: (@metinsa, @dncnwtts, @hermda02) Package Name: ZodiPy One-Line Description of Package: Zodiacal emission simulations in timestreams or HEALPix for solar system observers. Repository Link: https://github.com/Cosmoglobe/zodipy Version submitted: v.0.8.5 Editor: @dhomeier Reviewer 1: @pllim
Reviewer 2: @lpsinger
Archive: JOSS DOI: Version accepted: v.0.9.2 Date accepted (month/day/year): 04/21/2024
Code of Conduct & Commitment to Maintain Package
Description
ZodiPy is a new Python tool for modelling the zodiacal emission seen by an arbitrary Solar System observer, which can be used for removal of both thermal emission and scattered sunlight from interplanetary dust in astrophysical data. One of our main goals with ZodiPy is to make zodiacal emission simulations more accessible by providing the community with a simple Python interface to existing models. We recently published a paper on ZodiPy (which has also been accepted to A&A) where we describe in more detail modelling of zodiacal emission and the approach taken by ZodiPy.
ZodiPy uses Astropy both in the public API and internally. When using one of the methods provided to simulate the zodiacal emission, the user needs to use
Quantity
andTime
types in input arguments such as frequency/wavelength, angles on the sky, and the time of observation. Internally, the Time object is used to compute the heliocentric ecliptic position of the Earth and the observer with theSkyCoord
and other functionality inastropy.coordinates
.Scope
Please indicate which category or categories. Check out our package scope page to learn more about our scope. (If you are unsure of which category you fit, we suggest you make a pre-submission inquiry):
ZodiPy was already proposed and reviewed as an Astropy Affiliated package before the recent partnership between Astropy and pyOpenSci in APE22, so I am resubmitting the proposal as is here.
Domain Specific
Community Partnerships
If your package is associated with an existing community please check below:
For all submissions, explain how the and why the package falls under the categories you indicated above. In your explanation, please address the following points (briefly, 1-2 sentences for each):
Who is the target audience and what are scientific applications of this package?
Are there other Python packages that accomplish the same thing? If so, how does yours differ?
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:Technical checks
For details about the pyOpenSci packaging requirements, see our packaging guide. Confirm each of the following by checking the box. This package:
Publication Options
JOSS Checks
- [x] The package has an **obvious research application** according to JOSS's definition in their [submission requirements][JossSubmissionRequirements]. 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. - [x] The package is not a "minor utility" as defined by JOSS's [submission requirements][JossSubmissionRequirements]: "Minor ‘utility’ packages, including ‘thin’ API clients, are not acceptable." pyOpenSci welcomes these packages under "Data Retrieval", but JOSS has slightly different criteria. - [x] The package contains a `paper.md` matching [JOSS's requirements][JossPaperRequirements] with a high-level description in the package root or in `inst/`. - [x] The package is deposited in a long-term repository with the DOI: *Note: JOSS accepts our review as theirs. You will NOT need to go through another full review. JOSS will only review your paper.md file. Be sure to link to this pyOpenSci issue when a JOSS issue is opened for your package. Also be sure to tell the JOSS editor that this is a pyOpenSci reviewed package once you reach this step.*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.
Confirm each of the following by checking the box.
Please fill out our survey
P.S. Have feedback/comments about our review process? Leave a comment here
Editor and Review Templates
The editor template can be found here.
The review template can be found here.