Ropenaq package for R #24
Comments
@masalmon Thanks for your submission. We are looking for reviewers now. |
Ok, thanks for the update! |
ReviewGeneral Comments
rOpenSci Packaging Guidelines
|
Thanks a lot @ateucher for your thorough and very useful review! I'll start working on this as soon as possible. It will make the package really better, thank you! I guess there is no devtools function for easily changing the name of the package? I bitterly regret naming it too fast. |
@masalmon it was my pleasure - I really enjoyed doing it :) If there's anything you run into that you need help with, ping me in an issue and/or on twitter. Also, I am definitely not an expert on |
@masalmon, I should have linked to this in my review: Here's the httr vignette on writing API packages: https://cran.r-project.org/web/packages/httr/vignettes/api-packages.html |
@ateucher cool, and again, thank you! I hope you'll like the final result. |
nice work on the review @ateucher @masalmon happy to answer any httr
|
review of RopenaqI really like this package! Its an elegant means of accessing a very interesting (and large!) online database. I have a few pieces of advice that I think will make the code more modular and easy to develop as it grows. And grow it will, because it is quite useful indeed! generali had quite a challenge to try to run this package! I am using Linux (Ubuntu 14.04), and for the longest time I could not get R to talk to the API. This was extra frustrating, because i was able to use the API from To correct the problem I had to run apt-get install libcurl4-openssl-dev I also uninstalled then reinstalled
You can apparently find out if your user will be having this problem by running Function reviewsgeneral thoughts on API functionsI really like how you've got five functions, and each maps to the five different API queries that are available. I was thinking that the names of functions might be a bit similar to functions in other packages that also use geography. What do you think of prefixing every function with a package-specific string? Perhaps something like I'd suggest using URL <- "https://api.openaq.org/v1/cities"
indonesia <- httr::GET(url = URL, query = list(country = "ID")) Status codes are also easily parsed with For parsing responses, I'd suggest you try out a two step approach - first use ## confirm that the response is what you expect:
grepl("json", headers(page)$`content-type`) # is there a better way?
## parsing content
contentPageText <- httr::content(page, as = "text")
jsonlite::fromJSON(contentPageText)
|
I really enjoyed reviewing this package! Thank you so much @sckott for the invitation, and thank you @masalmon for contributing such an interesting package. I learned a lot while reading your code. |
Thank you so much @aammd, this will be very helpful! I'm looking forward to implementing your advice! It's interesting to see how you and @ateucher have spotted different things, both reviews complete each other very well! I'm just wondering what you mean by references to lintr? I like having the lintr-bot tell me where my syntax is wrong each time I push something to Github. And if I let it here and get contributions from other people later, I can also check their code for "syntax compatibility" with mine. Regarding encoding: ropensci/ropenaq#4 Imagine an user wants to see which cities are available for Poland and then make a query with measurements for one of these cities. I provide cityURL because otherwise, you couldn't just do copy and paste in a query since with an e.g. French locale the accents of city names in Poland do not appear so what you see in a result of cities() wouldn't be the real name of the country (missing accents) and therefore the httr translation wouldn't be right either. So now I expect the user to provide the encoded version as argument, and I help him/her by providing the cityURL and locationURL column in all tables that have city and location. I had no better idea. Anyway, I'll start working on the package again next week and I already know it will get better thanks to both reviews, thanks again @ateucher and @aammd ! And thanks @sckott for the httr remark ! |
Ropenaq -- point-to-point answer to the reviewersThanks again for your very helpful and thorough reviews, @ateucher and @aammd ! When I'm a (R) grown up I want to be a Ropensci package reviewer too and make people happy and improve their code I'll answer to both of you in the same answer to avoid repeating myself. I was not sure how to structure my answer so I hope it'll be easy to read -- I thought that having a remark in italic/answer would be too cumbersome. Both reviews were well structured and easy to read! Please tell me if I missed something. General comments
rOpenSci Packaging Guidelines
DESCRIPTION fileI have made all changes. Dependencies
Function Usage and Documentation
Source Code
# does the query and then parses it
getResults <- function(urlAQ, argsList){
page <- httr::GET(url = urlAQ,
query = argsList)
# convert the http error to a R error
httr::stop_for_status(page)
contentPage <- httr::content(page, as = "text")
# parse the data
resTable <- jsonlite::fromJSON(contentPage)$results
resTable <- dplyr::tbl_df(resTable)
return(resTable)
} The suggestions you both made made it all very easy! I just wonder if having a simple
Tests
lintr
Vignettes
I hope I haven't missed anything. This review process is really very interesting. I can see that the package is getting better, and I can apply nearly everything I learnt to other R code/packages I have to write, so again, many thanks! PS: How can I acknowledge the reviewers' input in the DESCRIPTION file, @sckott ? |
Just giving some news about the package:
I'll come write a comment again when I'm done with the modifications because of the API change and with memoise (a few weeks at most). I hope that the editor @sckott is ok with this "strategy"! |
@masalmon yes, sounds good |
Note that there is a specific semantic for adding reviewers to the Author On Tue, Apr 12, 2016, 4:49 PM Scott Chamberlain notifications@github.com
|
I have now prepared a new version of the package. Important things to note:
Now I'll wait for feedback in order to finally make the package ready for transfer... and when the API becomes stable I'd like to submit it to CRAN which makes me a bit nervous. And again, thanks a lot for the previous feedback! |
@masalmon I would be delighted to be listed as a reviewer on this package! Its a really cool package and I enjoyed studying it. I would love to comment on the changes you've made -- I apologize for saying little in response to your awesome & extensive revisions. I confess it felt a little overwhelming! @sckott , what is the best way to go forward? Should I write another comment here? |
We don't make anyone change pkg name, but we do find it easier for users if they don't have to worry about case. If you change the name, github will redirect users automatically to the new repo name
@aammd if you have time, yes please! We realize your time is valuable, so comments don't have to be extensive |
Ok so changing the name will be my next step! |
Let me pre-emptively warn you about a real headscratcher re: travis: TL;DR manually change the travis slug in |
Thanks @jennybc, that's thoughtful! I'm quite lucky because this API does not require authentification, however I'll be careful if something bad happens on Appveyor (for which I encrypted my Github path and put the secret in the config file) since it might have similar issues I guess. |
It seems it was much easier than I had envisioned... So now this whole issue deals with a package called ropenaq. @aammd you're listed as a reviewer now in the DESCRIPTION. |
Based on a single repo of mine, it doesn't look like Appveyor puts info into |
Hi @masalmon , sorry or being so silent lately! I would be thrilled to be added as a reviewer, thanks you! I've been lurking and watching some of your work, am I think it looks awesome! Unfortunately I don't think I'll have time to do much more review on it in the short term, but if I have a chance I will peek in, as I am very interested and I know I can learn a lot from your work. |
@sckott, how should I proceed? I re-read my answers. My main doubts are now:
For a future version of ropenaq my goals are:
When the API is stable I want to make the package ready for CRAN submission. |
@masalmon I think we're ready to approve and have you move over your repo. I've marked it as approved. I'll close this issue, and move over to |
@sckott awesome, thank you! The "Transfer ownership" button is in the danger zone of settings which makes me a bit nervous, ah, but it seems pretty easy. Since I'm a member of |
I think you should be able to - try it and if it doesn't work I'll fix some things. We started the 2nd organization ropenscilabs for earlier stage packages/projects - once more mature they'll move to ropensci - |
@sckott ok thanks for explaining, now I'll transfert it! |
"Moving repository to ropenscilabs/ropenaq. This may take a few minutes." |
Cool I can see the redirection, so this is my last message here. |
It provides an interface to the OpenAQ API. OpenAQ provides open air quality data for many locations around the world, whose number is growing. The R package allows to check data availability and to download measurements from R as a dplyr data.table.
Package: Ropenaq Type: Package Title: The Package is a R Interface to the openaq API Version: 0.1 Date: 2015-12-30 Author: Maëlle Salmon Maintainer: Who to complain to <maelle.salmon@yahoo.se> Description: See https://docs.openaq.org/ License: GPL (version 2 or later) LazyData: TRUE RoxygenNote: 5.0.1 URL: http://github.com/masalmon/Ropenaq BugReports: http://github.com/masalmon/Ropenaq/issues Suggests: knitr, rmarkdown VignetteBuilder: knitr Depends: httr, lubridate, dplyr, testthat, XML
https://github.com/masalmon/Ropenaq
Open AQ https://openaq.org/#/
People that need air quality data for their studies and do not know how to access the API, or want to do the analysis in R anyway. They could be e.g. epidemiologists. I think that if the R package has users, the Open AQ platform will also get more attention and thus get even more data sources.
No, this is the first and only R package for accessing the OpenAQ API (I first asked one of the OpenAQ co-founders)
Yes, as much as I can.
When it is more developped, yes, it could be usefool.
devtools::check()
produce any errors or warnings? If so paste them below.The text was updated successfully, but these errors were encountered: