[REVIEW]: SEP: Source Extractor as a library

[whedon]

Submitting author: @kbarbary (Kyle Barbary)
Repository: https://github.com/kbarbary/sep
Version: v1.0.0
Editor: @arfon
Reviewer: @danielskatz
Archive: http://dx.doi.org/10.5281/zenodo.159035

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/aa9bcf7c898895f5338ef5934f99061b"><img src="http://joss.theoj.org/papers/aa9bcf7c898895f5338ef5934f99061b/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/aa9bcf7c898895f5338ef5934f99061b/status.svg)](http://joss.theoj.org/papers/aa9bcf7c898895f5338ef5934f99061b)

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 questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.6.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g. API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

Paper PDF: 10.21105.joss.00058.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• References: Do all archival references that should have a DOI list one (e.g. papers, datasets, software)?

[arfon]

/ cc @openjournals/joss-reviewers - would anyone be willing to review this submission?

If you would like to review this submission then please comment on this thread so that others know you're doing a review (so as not to duplicate effort). Something as simple as :hand: I am reviewing this will suffice.

Reviewer instructions

• Please work through the checklist at the start of this issue.
• If you need any further guidance/clarification take a look at the reviewer guidelines here http://joss.theoj.org/about#reviewer_guidelines
• Please make a publication recommendation at the end of your review

Any questions, please ask for help by commenting on this issue! 🚀

[danielskatz]

I will do this one.

[danielskatz]

I'm a bit uncertain about the license part. The repo has a licenses directory that contains 3 licenses, two as .md and one as .txt. Is the fact that some of these are in .md ok for JORS?

Also, the readme states "The license for all parts of the code derived from SExtractor is LGPLv3. The license for code not derived from SExtractor is MIT. The license for the library as a whole is therefore LGPLv3. The license for each file is explicitly stated at the top of each file and the full text of the licenses can be found in licenses." which is fairly clear, but it's not clear to me why the licenses file then contains the contains the BSD license as well.

[danielskatz]

Re versions: The repo talks about version 1.0 as not yet released, discusses 0.60 as the most recent release, and also points to a software archive that contains version 0.30. The paper says that there is no software archive yet.

If this JOSS submission is for version 0.60, there needs to be a software archive that contains the code from version 0.60.

[danielskatz]

I feel like the original reference
Bertin, E. & Arnouts, S. 1996: SExtractor: Software for source extraction, Astronomy & Astrophysics Supplement 317, 393. (doi: 10.1051/aas:1996164)
perhaps should be included, but this is up to the submitter.

[kbarbary]

Thanks for the review!

License: I removed the copy of the BSD license and corrected the file extensions of the MIT license to txt.

versions: I updated the link in the readme to point to the v0.6.0 zenodo archive. (v1.0.0 will be the next release of SEP which will remove deprecated features; it has not yet been released though).

citation: I added the Bertin & Arnouts (1996) citation to the paper.

[kbarbary]

Ah, now I remember why the BSD license was there. One file src/overlap.h is based on BSD-licensed code. I believe this means I should keep the text of the BSD license there.

I could change MIT -> BSD to simply things overall; I just had a slight preference for MIT, so I started with that.

[danielskatz]

so the readme should be changed to say this (not the details, but just that there is some BSD code too)

[danielskatz]

@arfon, how/when does the paper get regenerated?

[arfon]

@danielskatz - I currently have to do this. @whedon is gaining those super-powers soon.

[arfon]

Do we need a updated paper compiling?

[danielskatz]

yes please

[arfon]

@danielskatz here you go: 10.21105.joss.00058.pdf

[danielskatz]

re a statement of need in the paper: the repo readme probably should have a little of the paper content to explain what source extractor is and who might want to use it. This could also potentially go in docs/index.srt

The license info in docs/index.srt might need to be updated?

It would also be useful if the docs contained a simple tutorial/test - just one input, the code needed to do an analysis, and a correct output to compare against.