Tim Triche, Jr.
tim@triche @ending from gm@il@com
Sat Aug 18 19:11:23 CEST 2018
Vince beat me to it. Don’t use Kent utils unless you have to. If you have something like a bigBed parser, I could perhaps help clean it up. But if you’re doing anything that could possibly be done in Rsamtools or rtracklayer, I would join Vince in urging you to use their functions. You will have less maintenance burden if you do.
This list exists in part to keep package developers from immiserating themselves through misplaced enthusiasm 😉
> On Aug 18, 2018, at 12:46 PM, Vincent Carey <stvjc using channing.harvard.edu> wrote:
>> On Sat, Aug 18, 2018 at 12:17 PM, Ghiwa Khalil <gk39 using aub.edu.lb> wrote:
>> We are writing a package with 2 main functions, one of these functions
>> requires kent utils to be installed.
>> Since kent utils is supported by only specific operating systems, is it
>> recommended to have it in an R package?
>> If we remove this function then our package will only be based on one
>> function, we are not sure if it is clever to submit a package with one
>> function. We were thinking to keep the function based on kent utils and
>> consider it as an option for users able to use it.
>> Any thoughts on this issue?
> It is best to have packages that run on all platforms. The number of
> in a package is not an important determinant of usefulness.
> What exactly do you require from the "kent utils"? Have you checked
> for relevant functionality?
> You would get best guidance if you identified a github repo where your
> package is being developed. If you are concerned about exposure, you can
> invite a developer as a confidential evaluator/consultant. I would be
> to play this role if necessary.
> Vincent Carey
>> Thank you.
>> [[alternative HTML version deleted]]
>> Bioc-devel using r-project.org mailing list
> [[alternative HTML version deleted]]
> Bioc-devel using r-project.org mailing list
More information about the Bioc-devel