[REVIEW]: retworkx: A High-Performance Graph Library for Python

whedon commented 2 years ago

Submitting author: !--author-handle-->@IvanIsCoding@drvinceknight<!--end-editor-- Reviewers: @szhorvat, @inakleinbottle Archive: 10.5281/zenodo.7158473

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

Status

Status badge code:

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

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) by leaving comments 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

@szhorvat & @inakleinbottle, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

Make sure you're logged in to your GitHub account
Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @drvinceknight know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Review checklist for @szhorvat

✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨

Conflict of interest

[x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

[x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

[x] Repository: Is the source code for this software available at the repository url?
[x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
[x] Contribution and authorship: Has the submitting author (@IvanIsCoding) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
[x] Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

[x] Installation: Does installation proceed as outlined in the documentation?
[x] Functionality: Have the functional claims of the software been confirmed?
[x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
[x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
[x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
[x] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
[x] 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

[x] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
[x] A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
[x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
[x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
[x] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Review checklist for @inakleinbottle

✨ Important: Please do not use the Convert to issue functionality when working through this checklist, instead, please open any new issues associated with your review in the software repository associated with the submission. ✨

Conflict of interest

[ ] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

[ ] I confirm that I read and will adhere to the JOSS code of conduct.

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?
[ ] Contribution and authorship: Has the submitting author (@IvanIsCoding) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
[ ] Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

[ ] Installation: Does installation proceed as outlined in the documentation?
[ ] Functionality: Have the functional claims of the software been confirmed?
[ ] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

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 functionality 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

[ ] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
[ ] A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
[ ] State of the field: Do the authors describe how this software compares to other commonly-used packages?
[ ] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
[ ] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

IvanIsCoding commented 2 years ago

@drvinceknight We have addressed the remaining comments in the software paper

IvanIsCoding commented 2 years ago

Also, mind me pinging @hagberg, @dschult, @networkx. We are submitting our library, retworkx, to the Journal of Open Source Software. This is the open peer review of our submission.

Before publishing, I wanted to contact you to ask about how you feel about the name of our submission. This came up as one of our reviewer @szhorvat (igraph's maintainer) pointed out an obvious reference from retworkx to NetworkX. Indeed, the name of our library is an homage to your work (Rust + NetworkX).

Would you be comfortable if we published our library under the current title of retworkx? Or would you prefer if we changed the name of our library before publication?

dschult commented 2 years ago

I'll bring it up at the weekly core developers meeting this week to say what people feel about it. My first impression is that the one letter difference and the letters being r and n (which are so close) make it likely that users will get confused between the two. That is not in either of our best interests. There are many other good possibilities. In light of search engine optimization, you should make it distinctive from that perspective.
rustnet? or maybe something that highlights the type of analysis you focus on for your package?

I'll bring it up at our developer meeting and get back to you soon. Thanks for asking about it!

drvinceknight commented 2 years ago

@editorialbot check references

editorialbot commented 2 years ago

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.5281/zenodo.2583252 is OK
- 10.4230/LIPIcs.TQC.2019.3 is OK
- 10.1145/2663171.2663188 is OK
- 10.1145/2898361 is OK
- 10.6084/m9.figshare.1164194 is OK
- 10.1109/TPAMI.2004.75 is OK
- 10.1016/j.dam.2018.02.018 is OK
- 10.1017/nws.2016.20 is OK
- 10.5281/zenodo.4066866 is OK
- 10.48550/arXiv.2104.14722 is OK
- 10.1109/tc.2020.3023247 is OK
- 10.1103/revmodphys.94.015004 is OK
- 10.22331/q-2018-08-06-79 is OK

MISSING DOIs

- None

INVALID DOIs

- None

drvinceknight commented 2 years ago

@dschult I will wait to hear back from you before proceeding.

boothby commented 2 years ago

networkx dev here -- how do you feel about rustworkx?

mtreinish commented 2 years ago

@boothby for me obviously not renaming the library would be the best, because trying to manage compatibly and a migration of our existing user base (it's not exactly small either) is a lot of effort. But, yeah if you request we rename the library I was thinking something like rustworkx or some other name where we can preserve the rx shortcut to hopefully ease that transition for people.

dschult commented 2 years ago

The NetworkX devs would prefer that your package not be named so close to the name networkx. The names retworkx and networkx are too close for packages that don't try to provide the same API.

Almost all of us also thought retworkx wasn't a very good name. You probably want to make it clear that it is rust. Many also expressed that it would be really cool to have a drop-in Rust version where the API was the same. That way code developed using one package could just be used in the other package by changing the import statement. But we also understand the subtle choices that have to be made when developing a package. And we appreciate the work toward getting a Rust/Python network analysis tool.

Other good possible names: RustworkX Rustworks RustyNets NetRust -- something closer to the type of network analysis you are planning to do. Or closer to Qiskit.
QisNet networkQIS the list could go on...

I personally like QisNet but a lot depends on your long term vision for the package.

The end result is that we would prefer that you change the name.

IvanIsCoding commented 2 years ago

The NetworkX devs would prefer that your package not be named so close to the name networkx. The names retworkx and networkx are too close for packages that don't try to provide the same API.

Almost all of us also thought retworkx wasn't a very good name. You probably want to make it clear that it is rust. Many also expressed that it would be really cool to have a drop-in Rust version where the API was the same. That way code developed using one package could just be used in the other package by changing the import statement. But we also understand the subtle choices that have to be made when developing a package. And we appreciate the work toward getting a Rust/Python network analysis tool.

Other good possible names: RustworkX Rustworks RustyNets NetRust -- something closer to the type of network analysis you are planning to do. Or closer to Qiskit. QisNet networkQIS the list could go on...

I personally like QisNet but a lot depends on your long term vision for the package.

The end result is that we would prefer that you change the name.

Thanks for the response, we will keep track of the change of name proposal in https://github.com/Qiskit/retworkx/issues/641.

The rollout of this is more complicated than just changing the name of the paper. There is quite a few users depending on us so as Matthew highlighted.

@boothby for me obviously not renaming the library would be the best, because trying to manage compatibly and a migration of our existing user base (it's not exactly small either) is a lot of effort. But, yeah if you request we rename the library I was thinking something like rustworkx or some other name where we can preserve the rx shortcut to hopefully ease that transition for people.

I personally suggest reseaux for the new package name. It comes from the French réseaux, and literally means "networks". The imports would be import reseaux as rx which is very close toimport retworkx as rx

IvanIsCoding commented 2 years ago

@editorialbot generate pdf

editorialbot commented 2 years ago

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

IvanIsCoding commented 2 years ago

@editorialbot help

editorialbot commented 2 years ago

Hello @IvanIsCoding, here are the things you can ask me to do:


# List all available commands
@editorialbot commands

# Get a list of all editors's GitHub handles
@editorialbot list editors

# Check the references of the paper for missing DOIs
@editorialbot check references

# Perform checks on the repository
@editorialbot check repository

# Adds a checklist for the reviewer using this command
@editorialbot generate my checklist

# Set a value for branch
@editorialbot set joss-paper as branch

# Generates the pdf paper
@editorialbot generate pdf

# Get a link to the complete list of reviewers
@editorialbot list reviewers

IvanIsCoding commented 2 years ago

@editorialbot commands

editorialbot commented 2 years ago

Hello @IvanIsCoding, here are the things you can ask me to do:


# List all available commands
@editorialbot commands

# Get a list of all editors's GitHub handles
@editorialbot list editors

# Check the references of the paper for missing DOIs
@editorialbot check references

# Perform checks on the repository
@editorialbot check repository

# Adds a checklist for the reviewer using this command
@editorialbot generate my checklist

# Set a value for branch
@editorialbot set joss-paper as branch

# Generates the pdf paper
@editorialbot generate pdf

# Get a link to the complete list of reviewers
@editorialbot list reviewers

IvanIsCoding commented 2 years ago

@drvinceknight @arfon We have changed the name of the library to be rustworkx and need to update the title and repository link. "rustworkx: A High-Performance Graph Library for Python" and https://github.com/Qiskit/rustworkx

I did not find the command to change them, can you help us update those? .

arfon commented 2 years ago

@editorialbot set https://github.com/Qiskit/rustworkx as repository

editorialbot commented 2 years ago

Done! repository is now https://github.com/Qiskit/rustworkx

IvanIsCoding commented 2 years ago

@arfon @drvinceknight We have officially released the library under the name of rustworkx.

We have archived the library in Zenodo, can you help set up the archive with editorialbot? https://doi.org/10.5281/zenodo.7158473

danielskatz commented 2 years ago

👋 @drvinceknight - this seems like it's waiting for you...

danielskatz commented 2 years ago

@IvanIsCoding - please update the metadata in your zenodo deposit to change the title to match the title of the software paper

IvanIsCoding commented 2 years ago

@IvanIsCoding - please update the metadata in your zenodo deposit to change the title to match the title of the software paper

We have updated the title, it matches the paper’s title now

danielskatz commented 2 years ago

Thanks - @drvinceknight should now do a check on this and recommend it be accepted, then I will take over for the last steps.

danielskatz commented 2 years ago

@IvanIsCoding - @drvinceknight is quite busy now, so I will handle the rest of the process

danielskatz commented 2 years ago

@editorialbot set 10.5281/zenodo.7158473 as archive

editorialbot commented 2 years ago

Done! Archive is now 10.5281/zenodo.7158473

danielskatz commented 2 years ago

@editorialbot set 0.12.0 as version

editorialbot commented 2 years ago

Done! version is now 0.12.0

danielskatz commented 2 years ago

@editorialbot recommend-accept

editorialbot commented 2 years ago

Attempting dry run of processing paper acceptance...

editorialbot commented 2 years ago

:warning: Error preparing paper acceptance. The generated XML metadata file is invalid.

ID figU003Adagexample already defined

editorialbot commented 2 years ago

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.5281/zenodo.2583252 is OK
- 10.4230/LIPIcs.TQC.2019.3 is OK
- 10.1145/2663171.2663188 is OK
- 10.1145/2898361 is OK
- 10.6084/m9.figshare.1164194 is OK
- 10.1109/TPAMI.2004.75 is OK
- 10.1016/j.dam.2018.02.018 is OK
- 10.1017/nws.2016.20 is OK
- 10.5281/zenodo.4066866 is OK
- 10.48550/ARXIV.1811.04968 is OK
- 10.48550/arXiv.2104.14722 is OK
- 10.1109/tc.2020.3023247 is OK
- 10.1103/revmodphys.94.015004 is OK
- 10.22331/q-2018-08-06-79 is OK

MISSING DOIs

- None

INVALID DOIs

- None

danielskatz commented 2 years ago

@IvanIsCoding in your paper.md file, you have 2 figures that use the same label (\label{fig:dagexample}) - please change one of them to something different

IvanIsCoding commented 2 years ago

@IvanIsCoding in your paper.md file, you have 2 figures that use the same label (\label{fig:dagexample}) - please change one of them to something different

I have updated the label, it should work now

IvanIsCoding commented 2 years ago

@editorialbot generate pdf

editorialbot commented 2 years ago

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

danielskatz commented 2 years ago

@editorialbot recommend-accept

editorialbot commented 2 years ago

Attempting dry run of processing paper acceptance...

editorialbot commented 2 years ago

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.5281/zenodo.2583252 is OK
- 10.4230/LIPIcs.TQC.2019.3 is OK
- 10.1145/2663171.2663188 is OK
- 10.1145/2898361 is OK
- 10.6084/m9.figshare.1164194 is OK
- 10.1109/TPAMI.2004.75 is OK
- 10.1016/j.dam.2018.02.018 is OK
- 10.1017/nws.2016.20 is OK
- 10.5281/zenodo.4066866 is OK
- 10.48550/ARXIV.1811.04968 is OK
- 10.48550/arXiv.2104.14722 is OK
- 10.1109/tc.2020.3023247 is OK
- 10.1103/revmodphys.94.015004 is OK
- 10.22331/q-2018-08-06-79 is OK

MISSING DOIs

- None

INVALID DOIs

- None

editorialbot commented 2 years ago

:wave: @openjournals/csism-eics, this paper is ready to be accepted and published.

Check final proof :point_right::page_facing_up: Download article

If the paper PDF and the deposit XML files look good in https://github.com/openjournals/joss-papers/pull/3659, then you can now move forward with accepting the submission by compiling again with the command @editorialbot accept

danielskatz commented 2 years ago

Sorry all, I now realize I may have jumped the gun slightly, as I'm not sure that the reviewers are fully satisfied with publication, based on the checklists and my review of the full issue here, so I will ask next before we proceed.

danielskatz commented 2 years ago

👋 @szhorvat, @inakleinbottle - can you confirm that you are ready for this submission to be accepted and published?

szhorvat commented 2 years ago

Confirmed.

danielskatz commented 1 year ago

👋 @inakleinbottle - can you confirm that you are ready for this submission to be accepted and published?

inakleinbottle commented 1 year ago

@danielskatz Sorry for the delay. Yes, all of my concerns have been addressed. I still cannot tick the boxes in the review post which is why they are not filled in.

danielskatz commented 1 year ago

👋 @IvanIsCoding - I've now proofread the paper, and have made suggestions for small changes in https://github.com/Qiskit/rustworkx/pull/720 - please merge this, or let me know what you disagree with, then we can finish the process

danielskatz commented 1 year ago

@editorialbot recommend-accept

final check before publishing...

editorialbot commented 1 year ago

Attempting dry run of processing paper acceptance...

editorialbot commented 1 year ago

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.5281/zenodo.2583252 is OK
- 10.4230/LIPIcs.TQC.2019.3 is OK
- 10.1145/2663171.2663188 is OK
- 10.1145/2898361 is OK
- 10.6084/m9.figshare.1164194 is OK
- 10.1109/TPAMI.2004.75 is OK
- 10.1016/j.dam.2018.02.018 is OK
- 10.1017/nws.2016.20 is OK
- 10.5281/zenodo.4066866 is OK
- 10.48550/ARXIV.1811.04968 is OK
- 10.48550/arXiv.2104.14722 is OK
- 10.1109/tc.2020.3023247 is OK
- 10.1103/revmodphys.94.015004 is OK
- 10.22331/q-2018-08-06-79 is OK

MISSING DOIs

- None

INVALID DOIs

- None

openjournals / joss-reviews