Closed vmorozov closed 9 years ago
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://cla.developers.google.com/ to sign.
Once you've signed, please reply here (e.g. I signed it!
) and we'll verify. Thanks.
@vmorozov thanks for this
The example in getAnyPage help shows "readgroupsets/search" which works right now via getSearchPage
. Which other APIs in particular would you like to be able to call from the R client? (sounds like perhaps import reads and variants?) The full list of APIs is here.
Here's what I think would be the prioritized list of methods to add. I'm curious to know what you and others think?
Without knowing much about this, I would recommend a high-level interface that lets people write stuff like:
subset(callsets(genomics), sample=="A")
Instead of calling something like genomics.callsets.search
.
@lawremi, thank you for your suggestion. It makes perfect sense. A deep integration with generic methods for Bioconductor objects (or even without Bioconductor, like providing an implementation of the subset method in your example above) is in the works but will take some more time as it is not very high priority and needs to be designed properly. The end result should be that people should be able to swap out a BAM file for the genomics API with only configuration changes and no actual code changes.
In the meanwhile, we can complete the rest of the API for this package in the existing layered approach as this can be done very quickly.
(Derail)
Are youse guise planning to do a workshop on the google genomics R client at BioC2015? Because that would be an awesome way to get tons of feedback (and users!) fast.
--t
On Apr 22, 2015, at 12:05 PM, Siddhartha Bagaria notifications@github.com wrote:
@lawremi, thank you for your suggestion. It makes perfect sense. A deep integration with generic methods for Bioconductor objects (or even without Bioconductor, like providing an implementation of the subset method in your example above) is in the works but will take some more time as it is not very high priority and needs to be designed properly. The end result should be that people should be able to swap out a BAM file for the genomics API with only configuration changes and no actual code changes.
In the meanwhile, we can complete the rest of the API for this package in the existing layered approach as this can be done very quickly.
— Reply to this email directly or view it on GitHub.
@ttriche Yes, Sid and I will be there :-) http://www.bioconductor.org/help/course-materials/2015/BioC2015/
With regard to generics and the API, is there a reason that we (Bioc and Google) couldn't collaborate on this, with the goal being a new google genomics package? We (Bioc) have structured a couple of other projects to have monthly conference calls for discussion and then work electronically via version control (including API design, etc.). I'm not sure how this would work from a licensing point-of-view, but having Bioc developers directly involved would potentially facilitate the development process a bit. Just a thought....
@seandavi +1 for collaborating in general and particularly on BioC generics! I will follow up with you directly via email for meeting logistics.
My suggestion was to have something generic now. Tighter integration with/into BioC sounds great! Regarding what methods to wrap into R function, the Python API methods https://developers.google.com/resources/api-libraries/documentation/genomics/v1beta2/python/latest/index.html look as reasanable starting point for the R API (:.
It might be good idea to have a generic API call function. Then a workflow can be run in R (see example in getAnyPage help) New argument 'scope' is added into 'autheticate' function to anable arbitrary API calls. My changes in getSearchPage can be ignored. if the generic API function exists, getSearchPage should be just wrapper for the generic (getAnyPage) function