Group 9 - SpotifyAssistantR

name: SpotifyAssistantR about: Building on top of the existing `spotifyr` package and providing additional insights for Spotify users

Submitting Authors: Caroline Tang, Julie Song, Jenit Jain, Chester Wang Package Authors Github handles: (comma separated, delete if none) @carolinetang77, @YXIN15, @brabbit61, @ChesterAiGo Repository: https://github.com/UBC-MDS/SpotifyAssistantR Version submitted: 1.0.0 Submission type: Standard Editor: Caroline Tang @carolinetang77, Julie Song @YXIN15, Jenit Jain @brabbit61, Chester Wang @ChesterAiGo Reviewers: Luke Yang, Ke Wang, Arjun Radhakrishnan, Waiel Tinwala Language: en

Paste the full DESCRIPTION file inside a code block below:

Package: SpotifyAssistantR
Title: Enrich Spotify User Experience
Version: 0.0.0.9000
Authors@R: 
    c(person("Jenit", "Jain", , "jenitjain10@gmail.com", role = c("aut", "cre")),
    person("Julie", "Song", , "juliesong525@gmail.com", role = c("aut")),
    person("Caroline", "Tang", , "tangmaomao2000@gmail.com", role = c("aut")),
    person("Chester", "Wang", , "gengxingwang2019@u.northwestern.edu", role = c("aut"))
    )
Description: Providing additional insights for Spotify users by allowing them to explore their listening trends via REST APIs implemented for Spotify developers
License: MIT + file LICENSE
Encoding: UTF-8
Roxygen: list(markdown = TRUE)
RoxygenNote: 7.2.3
Depends:
    spotifyr,
    dplyr
Suggests: 
    testthat (>= 3.0.0),
    digest
Config/testthat/edition: 3

Scope

Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):
- [x] data retrieval
- [x] data extraction
- [ ] data munging
- [x] data deposition
- [ ] data validation and testing
- [ ] workflow automation
- [ ] version control
- [ ] citation management and bibliometrics
- [ ] scientific software wrappers
- [ ] field and lab reproducibility tools
- [ ] database software bindings
- [ ] geospatial data
- [ ] text analysis
Explain how and why the package falls under these categories (briefly, 1-2 sentences): This package retrieves and combines data from Spotify REST APIs, returning information in a simpler format than the original API response.
Who is the target audience and what are scientific applications of this package? Spotify users who wish to gain more insight into their listening trends, create playlists from recommended songs, and see the most popular releases by continent.
Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category? This package is similar to the spotifyr package, which provides wrapper functions for each possible Spotify API call. However, we combine these API calls to provide new insights such as a user's top genres.
Explain reasons for any pkgcheck items which your package is unable to pass.

Technical checks

Confirm each of the following by checking the box.

[x] I have read the rOpenSci packaging guide.
[x] I have read the author guide and I expect to maintain this package for at least 2 years or to find a replacement.

This package:

[x] does not violate the Terms of Service of any service it interacts with.
[ ] has a CRAN and OSI accepted license.
[x] contains a README with instructions for installing the development version.
[x] includes documentation with examples for all functions, created with roxygen2.
[ ] contains a vignette with examples of its essential functions and uses.
[x] has a test suite.
[ ] has continuous integration, including reporting of test coverage.

Publication options

[ ] Do you intend for this package to go on CRAN?
[ ] Do you intend for this package to go on Bioconductor?
[ ] Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:

MEE Options

- [ ] The package is novel and will be of interest to the broad readership of the journal. - [ ] The manuscript describing the package is no longer than 3000 words. - [ ] You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see [MEE's Policy on Publishing Code](http://besjournals.onlinelibrary.wiley.com/hub/journal/10.1111/(ISSN)2041-210X/journal-resources/policy-on-publishing-code.html)) - (*Scope: Do consider MEE's [Aims and Scope](http://besjournals.onlinelibrary.wiley.com/hub/journal/10.1111/(ISSN)2041-210X/aims-and-scope/read-full-aims-and-scope.html) for your manuscript. We make no guarantee that your manuscript will be within MEE scope.*) - (*Although not required, we strongly recommend having a full manuscript prepared when you submit here.*) - (*Please do not submit your package separately to Methods in Ecology and Evolution*)

Code of conduct

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

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

Briefly describe any working relationship you have (had) with the package authors.
[x] 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:

[x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
[x] Installation instructions: for the development version of package and any non-standard dependencies in README
[x] Vignette(s): demonstrating major functionality that runs successfully locally
[x] Function Documentation: for all exported functions
[x] Examples: (that run successfully locally) for all exported functions
[x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing: 1

[x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

A NEWS

The R project is well-documented and easy to follow! Great job!
It might be helpful to put on the available badges and pass docs.
I think there is an option to add credentials as GitHub secrets to your workflow to test your API calls. Using this might get around with pre-loaded artist info and get more coverage on your code.
A future development could be to update your get_all_genres according to the online API instead of using fixed output.
Generally, the design is concise and the structure of the project is easy to understand

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

Briefly describe any working relationship you have (had) with the package authors.
[x] 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:

[x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
[x] Installation instructions: for the development version of package and any non-standard dependencies in README
[x] Vignette(s): demonstrating major functionality that runs successfully locally
[x] Function Documentation: for all exported functions
[x] Examples: (that run successfully locally) for all exported functions
[x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing: 1.5

[x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

The entire project is very well organized and documented. The package has an adequate ci-cd pipeline setup and working. Hosting the package on Github Pages makes it much easier to follow. Congrats to the team!!
I found the overall code coverage to be quite low (about 15%). While a super high Code coverage is probably not too important, I believe increasing it would make the project much less prone to bugs and breakage as the project grows in the future.
Currently, the package has a list of genres which it uses as a universal genre list. The fixed nature of this list would make it less robust as time goes since newer genres would not be recognized and the package would need to be manually updated every now and then.
The package does succeed at what it is meant to be. I was easily able to use the available functionalities without any trouble. I would love to see what more functionality gets added overtime (perhaps some graphs and plots).
As I currently understand, the user has to set the API keys as environment variables every time they start Rstudio. Setting them every single time is redundant and It would be a huge quality change to just include a little section in the README stating how to set these keys permanently.

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

Briefly describe any working relationship you have (had) with the package authors.
[x] 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:

[x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
[x] Installation instructions: for the development version of package and any non-standard dependencies in README
[x] Vignette(s): demonstrating major functionality that runs successfully locally
[x] Function Documentation: for all exported functions
[x] Examples: (that run successfully locally) for all exported functions
[x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing: 1.5 Hours

[x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

I've noticed that all commits and PR requests have clear and concise titles and descriptions. There are no unnecessary files committed to the repository as well. Overall, you've maintained good git hygiene. Kudos!
Code is well structured, with the functions being clearly defined and separated making the code easier to maintain, test, and understand for future developers.
It would be beneficial to include relevant missing badges in your repository so that users can have a more comprehensive understanding of the current status of the project when browsing the repo.
Checking the code coverage here, I could understand that most parts of the code are not covered. I recommend adding more tests to ensure your code is working as expected. It would also help avoid regression issues.
File names such as my-vignette.Rmd could be renamed so that it is user-friendly and clear in intent.
One suggestion for improvement is that the code cells in the main ReadMe could be broken down for each of the functions so that it is easier for the users interested in copy-pasting the commands.

Overall, the package is really interesting and engaging, especially for all music enthusiasts! It offers some amazing functions as well which I really enjoyed looking into. Thank you!

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

Briefly describe any working relationship you have (had) with the package authors.
[x] 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:

[x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
[x] Installation instructions: for the development version of package and any non-standard dependencies in README
[x] Vignette(s): demonstrating major functionality that runs successfully locally
[x] Function Documentation: for all exported functions
[x] Examples: (that run successfully locally) for all exported functions
[x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing: 1 hour

[x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

The README instruction is very detailed on how to get the API userId and userSecret.
For some reason I wasn't able to run the example usage code. I guess there's something wrong with my account or developer's token. For example running get_playlists_songs(playlist_names = 'bops') redirected me to browser. So the suggestions below are only based on looking at the code/repo.
I love how the source code is well organized. Top level functions are seperated in different files and there are helper functions in each file, instead of putting everything into a single function or a single file.
Each function is very well documented. When I look at the documentation website, I even feel like they are "over" documented because even the lower level helper functions have API references in the site. I think it would be better to hide those funtions in the doc because those are technically "private" functions which shouldn't be exposed to users. However I don't know in R languae if there's a way to make functions "private".
Some Roxygen examples sections are denoted as "dont run". I guess this is to avoid authentication error when running rcmdcheck(). Yeah this project is depending on web APIs and Spotify's authentication, which makes the tests a little bit tricky.
The test cases are pretty comprehensive and I like the idea of putting test data into csv and Rdata files.

UBC-MDS / software-review-2023