Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-12 Thread Bhagwat, Aditya
Thankyou Bernat!

-Original Message-
From: Bernat Gel Moreno  
Sent: Donnerstag, 12. September 2019 11:26
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

I have updated karyoploteR and it's now (from version 1.11.9 in devel) possible 
to use a BSgenome object or a seqinfo object as genome definitions in 
plotKaryotype. In both cases, if possible, it will by default automatically 
filter the chromosomes to the canonical ones (if
defined) and retrieve the cytobands for the genome. Or you can specify the 
exact chromosomes you want to plot. I think this should help with the specific 
question at hand.

Bernat


El 9/12/19 a las 10:09 AM, Bernat Gel Moreno escribió:
> Oh, and Aditya, take into account taht if you give karyoploteR a 
> custom genome as you are planning to do, it will not paint the 
> cytobands by default, you'll have to get them yourself and give them to 
> plotKaryotype.
>
> If possible, I would recommend giving the genome by name ("hg19") and 
> selecting the chromosomes to plot using "chromosomes".
>
> Bernat
>
>
>
>
> El 9/12/19 a las 8:47 AM, Bernat Gel Moreno escribió:
>> Hi all,
>>
>> I'm the developer of karyoploteR.
>>
>> @Michael: I never though about using seqinfo as the source for the 
>> genome information. I'll add this as an option to define the genome.
>> Thanks for the suggestion.
>>
>> @Aditya: If you want to plot just your relevant chromosomes, you 
>> don't need to alter the genome. You can use the "chromosomes" 
>> parameter to give a vector of chromosome names. Is it not working for 
>> you for some reason?
>>
>> Bernat
>>
>>
>> El 9/11/19 a las 2:31 PM, Michael Lawrence via Bioc-devel escribió:
>>> I'm pretty surprised that the karyoploteR package does not accept a 
>>> Seqinfo since it is plotting chromosomes. But again, please consider 
>>> just doing as(seqinfo(bsgenome), "GRanges").
>>>
>>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya 
>>>  wrote:
>>>> Hi Herve,
>>>>
>>>> Thank you for your responses.
>>>>From your response, it is clear that the vcountPDict use case does not 
>>>> need a BSgenome -> GRanges coercer.
>>>>
>>>> The karyoploteR use case still requires it, though, to allow plotting of 
>>>> only the chromosomal BSgenome portions:
>>>>
>>>>chromranges <- as(bsegenome, "GRanges")
>>>>kp <- karyoploteR::plotKaryotype(chromranges)
>>>>    karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>>
>>>> Or do you see any alternative for this purpose too?
>>>>
>>>> Aditya
>>>>
>>>> 
>>>> From: Pages, Herve [hpa...@fredhutch.org]
>>>> Sent: Wednesday, September 11, 2019 12:24 PM
>>>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>>> BiocGenerics (and others)?
>>>>
>>>> Hi Aditya,
>>>>
>>>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>>>> Hi Herve,
>>>>>
>>>>>
>>>>> > It feels that a coercion method from BSgenome to GRanges 
>>>>> should rather be defined in the BSgenome package itself.
>>>>>
>>>>> :-)
>>>>>
>>>>>
>>>>> > Patch/PR welcome on GitHub.
>>>>>
>>>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>>>
>>>>>
>>>>> > Is this what you have in mind for this coercion?
>>>>> > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>>>
>>>>> Yes.
>>>>>
>>>>> Perhaps also useful to share the wider context, allowing your and 
>>>>> others feedback for improved software design.
>>>>> I wanted to subset a
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioc
>>>>> onductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeA
>>>>> vimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK
>>>>> 7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>B
>>>>> Sgenome (without the _random or _unassigned), but Lori explained 
>>>>> this is not possible.
>>>>> <h

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-12 Thread Bhagwat, Aditya
Thankyou Bernat, 

Saw your email just now - since I have the "digest" option. Good that you 
brought the chromosomes parameter under my attention, I must be able to use 
that!

Aditya


-Original Message-
From: Bernat Gel Moreno  
Sent: Donnerstag, 12. September 2019 08:47
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

Hi all,

I'm the developer of karyoploteR.

@Michael: I never though about using seqinfo as the source for the genome 
information. I'll add this as an option to define the genome. 
Thanks for the suggestion.

@Aditya: If you want to plot just your relevant chromosomes, you don't need to 
alter the genome. You can use the "chromosomes" parameter to give a vector of 
chromosome names. Is it not working for you for some reason?

Bernat


El 9/11/19 a las 2:31 PM, Michael Lawrence via Bioc-devel escribió:
> I'm pretty surprised that the karyoploteR package does not accept a 
> Seqinfo since it is plotting chromosomes. But again, please consider 
> just doing as(seqinfo(bsgenome), "GRanges").
>
> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya 
>  wrote:
>> Hi Herve,
>>
>> Thank you for your responses.
>>  From your response, it is clear that the vcountPDict use case does not need 
>> a BSgenome -> GRanges coercer.
>>
>> The karyoploteR use case still requires it, though, to allow plotting of 
>> only the chromosomal BSgenome portions:
>>
>>  chromranges <- as(bsegenome, "GRanges")
>>  kp <- karyoploteR::plotKaryotype(chromranges)
>>  karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>
>> Or do you see any alternative for this purpose too?
>>
>> Aditya
>>
>> ____________
>> From: Pages, Herve [hpa...@fredhutch.org]
>> Sent: Wednesday, September 11, 2019 12:24 PM
>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>> BiocGenerics (and others)?
>>
>> Hi Aditya,
>>
>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>> Hi Herve,
>>>
>>>
>>>   > It feels that a coercion method from BSgenome to GRanges should 
>>> rather be defined in the BSgenome package itself.
>>>
>>> :-)
>>>
>>>
>>>   > Patch/PR welcome on GitHub.
>>>
>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>
>>>
>>>   > Is this what you have in mind for this coercion?
>>>   > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>
>>> Yes.
>>>
>>> Perhaps also useful to share the wider context, allowing your and 
>>> others feedback for improved software design.
>>> I wanted to subset a
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.biocon
>>> ductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvime
>>> WdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0a
>>> anQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
>>> (without the _random or _unassigned), but Lori explained this is not 
>>> possible.
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.biocon
>>> ductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvime
>>> WdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0a
>>> anQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
>>>
>>> Instead Lori suggested to coerce a BSgenome into a GRanges 
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.biocon
>>> ductor.org_p_123489=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvime
>>> WdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0a
>>> anQY4M6wY=6Eh73QthFfpPsfpRdPWs98pH6GHvv1Z23ORp34OCPxA=>,
>>> which is a useful solution, but for which currently no exported S4 
>>> method exists 
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.biocon
>>> ductor.org_p_124416=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvime
>>> WdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0a
>>> anQY4M6wY=H8owJlOQrNHwNFHfCxGHe27Jxu6xjxpuAMWK8JlTU4Y=>
>>> So I defined an S4 coercer in my multicrispr package, making sure to 
>>> properly import the Bsgenome class 
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124442=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=2XNBVcw

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-12 Thread Bernat Gel Moreno
I have updated karyoploteR and it's now (from version 1.11.9 in devel) 
possible to use a BSgenome object or a seqinfo object as genome 
definitions in plotKaryotype. In both cases, if possible, it will by 
default automatically filter the chromosomes to the canonical ones (if 
defined) and retrieve the cytobands for the genome. Or you can specify 
the exact chromosomes you want to plot. I think this should help with 
the specific question at hand.

Bernat


El 9/12/19 a las 10:09 AM, Bernat Gel Moreno escribió:
> Oh, and Aditya, take into account taht if you give karyoploteR a custom
> genome as you are planning to do, it will not paint the cytobands by
> default, you'll have to get them yourself and give them to plotKaryotype.
>
> If possible, I would recommend giving the genome by name ("hg19") and
> selecting the chromosomes to plot using "chromosomes".
>
> Bernat
>
>
>
>
> El 9/12/19 a las 8:47 AM, Bernat Gel Moreno escribió:
>> Hi all,
>>
>> I'm the developer of karyoploteR.
>>
>> @Michael: I never though about using seqinfo as the source for the
>> genome information. I'll add this as an option to define the genome.
>> Thanks for the suggestion.
>>
>> @Aditya: If you want to plot just your relevant chromosomes, you don't
>> need to alter the genome. You can use the "chromosomes" parameter to
>> give a vector of chromosome names. Is it not working for you for some
>> reason?
>>
>> Bernat
>>
>>
>> El 9/11/19 a las 2:31 PM, Michael Lawrence via Bioc-devel escribió:
>>> I'm pretty surprised that the karyoploteR package does not accept a
>>> Seqinfo since it is plotting chromosomes. But again, please consider
>>> just doing as(seqinfo(bsgenome), "GRanges").
>>>
>>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>>  wrote:
>>>> Hi Herve,
>>>>
>>>> Thank you for your responses.
>>>>From your response, it is clear that the vcountPDict use case does not 
>>>> need a BSgenome -> GRanges coercer.
>>>>
>>>> The karyoploteR use case still requires it, though, to allow plotting of 
>>>> only the chromosomal BSgenome portions:
>>>>
>>>>chromranges <- as(bsegenome, "GRanges")
>>>>kp <- karyoploteR::plotKaryotype(chromranges)
>>>>    karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>>
>>>> Or do you see any alternative for this purpose too?
>>>>
>>>> Aditya
>>>>
>>>> 
>>>> From: Pages, Herve [hpa...@fredhutch.org]
>>>> Sent: Wednesday, September 11, 2019 12:24 PM
>>>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>>> BiocGenerics (and others)?
>>>>
>>>> Hi Aditya,
>>>>
>>>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>>>> Hi Herve,
>>>>>
>>>>>
>>>>> > It feels that a coercion method from BSgenome to GRanges should
>>>>> rather be defined in the BSgenome package itself.
>>>>>
>>>>> :-)
>>>>>
>>>>>
>>>>> > Patch/PR welcome on GitHub.
>>>>>
>>>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>>>
>>>>>
>>>>> > Is this what you have in mind for this coercion?
>>>>> > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>>>
>>>>> Yes.
>>>>>
>>>>> Perhaps also useful to share the wider context, allowing your and others
>>>>> feedback for improved software design.
>>>>> I wanted to subset a
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
>>>>> (without the _random or _unassigned), but Lori explained this is not
>>>>> possible.
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
>>>>>
>>>>> Instead Lori suggested to coe

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-12 Thread Bhagwat, Aditya
Thanks Michael and Herve, 

Will do that then. 

I extract from this discussion that exporting a function in a core BioC package 
is reserved for functions 
(1) whose name unambiguously communicates what they do
(2) has the potential to be broadly used

And that as(BSgenome, 'GRanges') is being felt not not comply to these.

Thanks for all  the feedback - has been very helpful.

Aditya


From: Pages, Herve [hpa...@fredhutch.org]
Sent: Wednesday, September 11, 2019 5:29 PM
To: Michael Lawrence; Bhagwat, Aditya
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

Or more accurately:

   as(seqinfo(bsgenome)[seqlevelsInUse(grl)], "GRanges")

since not all seqlevels are necessarily "in use" (i.e. not necessarily
represented in seqnames(grl)).

H.

On 9/11/19 08:26, Hervé Pagès wrote:
> The unique seqnames is what we call the seqlevels. So just:
>
>as(seqinfo(bsgenome)[seqlevels(grl)], "GRanges")
>
> H.
>
> On 9/11/19 07:42, Michael Lawrence wrote:
>> So why not just do:
>>
>> as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")
>>
>> Michael
>>
>> On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
>>  wrote:
>>>
>>> Thanks Michael,
>>>
>>> The important detail is that I want to plot the relevant chromosomes
>>> only
>>>
>>>  relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
>>>  S4Vectors::runValue() %>%
>>>  Reduce(union, .) %>%
>>>  unique()
>>>
>>>  genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
>>>  as('GRanges') %>%
>>> (function(gr){
>>> gr [ as.character(GenomeInfoDb::seqnames(gr))
>>> %in%
>>>  relevant_chromosomes ]
>>> })
>>>
>>>  kp <- karyoploteR::plotKaryotype(genomeranges)
>>>  karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist
>>> contains crispr target sites
>>>
>>>
>>> And, this process required as("GRanges")
>>>
>>>  #' Convert BSgenome into GRanges
>>>  #' @param from BSgenome, e.g.
>>> BSgenome.Mmusculus.UCSC.mm10::Mmusculus
>>>  #' @examples
>>>  #' require(magrittr)
>>>  #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
>>>  #' as('GRanges')
>>>  #' @importClassesFrom BSgenome BSgenome
>>>  #' @export
>>>  methods::setAs( "BSgenome",
>>>          "GRanges",
>>>      function(from)  from %>%
>>>  GenomeInfoDb::seqinfo() %>%
>>>  as('GRanges'))
>>>
>>> Thankyou for feedback,
>>>
>>> Aditya
>>>
>>> 
>>> From: Michael Lawrence [lawrence.mich...@gene.com]
>>> Sent: Wednesday, September 11, 2019 2:31 PM
>>> To: Bhagwat, Aditya
>>> Cc: Pages, Herve; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching
>>> BiocGenerics (and others)?
>>>
>>> I'm pretty surprised that the karyoploteR package does not accept a
>>> Seqinfo since it is plotting chromosomes. But again, please consider
>>> just doing as(seqinfo(bsgenome), "GRanges").
>>>
>>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>>  wrote:
>>>>
>>>> Hi Herve,
>>>>
>>>> Thank you for your responses.
>>>>  From your response, it is clear that the vcountPDict use case does
>>>> not need a BSgenome -> GRanges coercer.
>>>>
>>>> The karyoploteR use case still requires it, though, to allow
>>>> plotting of only the chromosomal BSgenome portions:
>>>>
>>>>  chromranges <- as(bsegenome, "GRanges")
>>>>  kp <- karyoploteR::plotKaryotype(chromranges)
>>>>  karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>>
>>>> Or do you see any alternative for this purpose too?
>>>>
>>>> Aditya
>>>>
>>>> 
>>>> From: Pages, Herve [hpa...@fredhutch.org]
>>>&g

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-12 Thread Bernat Gel Moreno
Oh, and Aditya, take into account taht if you give karyoploteR a custom 
genome as you are planning to do, it will not paint the cytobands by 
default, you'll have to get them yourself and give them to plotKaryotype.

If possible, I would recommend giving the genome by name ("hg19") and 
selecting the chromosomes to plot using "chromosomes".

Bernat




El 9/12/19 a las 8:47 AM, Bernat Gel Moreno escribió:
> Hi all,
>
> I'm the developer of karyoploteR.
>
> @Michael: I never though about using seqinfo as the source for the
> genome information. I'll add this as an option to define the genome.
> Thanks for the suggestion.
>
> @Aditya: If you want to plot just your relevant chromosomes, you don't
> need to alter the genome. You can use the "chromosomes" parameter to
> give a vector of chromosome names. Is it not working for you for some
> reason?
>
> Bernat
>
>
> El 9/11/19 a las 2:31 PM, Michael Lawrence via Bioc-devel escribió:
>> I'm pretty surprised that the karyoploteR package does not accept a
>> Seqinfo since it is plotting chromosomes. But again, please consider
>> just doing as(seqinfo(bsgenome), "GRanges").
>>
>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>  wrote:
>>> Hi Herve,
>>>
>>> Thank you for your responses.
>>>   From your response, it is clear that the vcountPDict use case does not 
>>> need a BSgenome -> GRanges coercer.
>>>
>>> The karyoploteR use case still requires it, though, to allow plotting of 
>>> only the chromosomal BSgenome portions:
>>>
>>>   chromranges <- as(bsegenome, "GRanges")
>>>   kp <- karyoploteR::plotKaryotype(chromranges)
>>>   karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>
>>> Or do you see any alternative for this purpose too?
>>>
>>> Aditya
>>>
>>> 
>>> From: Pages, Herve [hpa...@fredhutch.org]
>>> Sent: Wednesday, September 11, 2019 12:24 PM
>>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>> BiocGenerics (and others)?
>>>
>>> Hi Aditya,
>>>
>>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>>> Hi Herve,
>>>>
>>>>
>>>>> It feels that a coercion method from BSgenome to GRanges should
>>>> rather be defined in the BSgenome package itself.
>>>>
>>>> :-)
>>>>
>>>>
>>>>> Patch/PR welcome on GitHub.
>>>>
>>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>>
>>>>
>>>>> Is this what you have in mind for this coercion?
>>>>> as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>>
>>>> Yes.
>>>>
>>>> Perhaps also useful to share the wider context, allowing your and others
>>>> feedback for improved software design.
>>>> I wanted to subset a
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
>>>> (without the _random or _unassigned), but Lori explained this is not
>>>> possible.
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
>>>>
>>>> Instead Lori suggested to coerce a BSgenome into a GRanges
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_123489=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=6Eh73QthFfpPsfpRdPWs98pH6GHvv1Z23ORp34OCPxA=>,
>>>> which is a useful solution, but for which currently no exported S4
>>>> method exists
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124416=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=H8owJlOQrNHwNFHfCxGHe27Jxu6xjxpuAMWK8JlTU4Y=>
>>>> So I defined an S4 coercer in my multicrispr package, making sure to
>>>> properly import the Bsgenome class
>>>> <https://urldefense.proof

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-12 Thread Bernat Gel Moreno
Hi all,

I'm the developer of karyoploteR.

@Michael: I never though about using seqinfo as the source for the 
genome information. I'll add this as an option to define the genome. 
Thanks for the suggestion.

@Aditya: If you want to plot just your relevant chromosomes, you don't 
need to alter the genome. You can use the "chromosomes" parameter to 
give a vector of chromosome names. Is it not working for you for some 
reason?

Bernat


El 9/11/19 a las 2:31 PM, Michael Lawrence via Bioc-devel escribió:
> I'm pretty surprised that the karyoploteR package does not accept a
> Seqinfo since it is plotting chromosomes. But again, please consider
> just doing as(seqinfo(bsgenome), "GRanges").
>
> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>  wrote:
>> Hi Herve,
>>
>> Thank you for your responses.
>>  From your response, it is clear that the vcountPDict use case does not need 
>> a BSgenome -> GRanges coercer.
>>
>> The karyoploteR use case still requires it, though, to allow plotting of 
>> only the chromosomal BSgenome portions:
>>
>>  chromranges <- as(bsegenome, "GRanges")
>>  kp <- karyoploteR::plotKaryotype(chromranges)
>>  karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>
>> Or do you see any alternative for this purpose too?
>>
>> Aditya
>>
>> ________
>> From: Pages, Herve [hpa...@fredhutch.org]
>> Sent: Wednesday, September 11, 2019 12:24 PM
>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>> BiocGenerics (and others)?
>>
>> Hi Aditya,
>>
>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>> Hi Herve,
>>>
>>>
>>>   > It feels that a coercion method from BSgenome to GRanges should
>>> rather be defined in the BSgenome package itself.
>>>
>>> :-)
>>>
>>>
>>>   > Patch/PR welcome on GitHub.
>>>
>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>
>>>
>>>   > Is this what you have in mind for this coercion?
>>>   > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>
>>> Yes.
>>>
>>> Perhaps also useful to share the wider context, allowing your and others
>>> feedback for improved software design.
>>> I wanted to subset a
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
>>> (without the _random or _unassigned), but Lori explained this is not
>>> possible.
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
>>>
>>> Instead Lori suggested to coerce a BSgenome into a GRanges
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_123489=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=6Eh73QthFfpPsfpRdPWs98pH6GHvv1Z23ORp34OCPxA=>,
>>> which is a useful solution, but for which currently no exported S4
>>> method exists
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124416=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=H8owJlOQrNHwNFHfCxGHe27Jxu6xjxpuAMWK8JlTU4Y=>
>>> So I defined an S4 coercer in my multicrispr package, making sure to
>>> properly import the Bsgenome class
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124442=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=2XNBVcwoJTjlxY_gl4UPzrHPKmKH9LTnM4ih5SQOfps=>.
>>> Then, after coercing a BSgenome into a GRanges, I can extract the
>>> chromosomes, after properly importing IRanges::`%in%`
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
>> Looks like you don't need to coerce the BSgenome object to GRanges. See
>> https://support.bioconductor.org/p/123489/#124581
>&

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Michael Lawrence via Bioc-devel
Good call. Didn't know about seqlevelsInUse().

On Wed, Sep 11, 2019 at 8:29 AM Pages, Herve  wrote:
>
> Or more accurately:
>
>as(seqinfo(bsgenome)[seqlevelsInUse(grl)], "GRanges")
>
> since not all seqlevels are necessarily "in use" (i.e. not necessarily
> represented in seqnames(grl)).
>
> H.
>
> On 9/11/19 08:26, Hervé Pagès wrote:
> > The unique seqnames is what we call the seqlevels. So just:
> >
> >as(seqinfo(bsgenome)[seqlevels(grl)], "GRanges")
> >
> > H.
> >
> > On 9/11/19 07:42, Michael Lawrence wrote:
> >> So why not just do:
> >>
> >> as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")
> >>
> >> Michael
> >>
> >> On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
> >>  wrote:
> >>>
> >>> Thanks Michael,
> >>>
> >>> The important detail is that I want to plot the relevant chromosomes
> >>> only
> >>>
> >>>  relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
> >>>  S4Vectors::runValue() %>%
> >>>  Reduce(union, .) %>%
> >>>  unique()
> >>>
> >>>  genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
> >>>  as('GRanges') %>%
> >>> (function(gr){
> >>> gr [ as.character(GenomeInfoDb::seqnames(gr))
> >>> %in%
> >>>  relevant_chromosomes ]
> >>> })
> >>>
> >>>  kp <- karyoploteR::plotKaryotype(genomeranges)
> >>>  karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist
> >>> contains crispr target sites
> >>>
> >>>
> >>> And, this process required as("GRanges")
> >>>
> >>>  #' Convert BSgenome into GRanges
> >>>  #' @param from BSgenome, e.g.
> >>> BSgenome.Mmusculus.UCSC.mm10::Mmusculus
> >>>  #' @examples
> >>>  #' require(magrittr)
> >>>  #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
> >>>  #' as('GRanges')
> >>>      #' @importClassesFrom BSgenome BSgenome
> >>>  #' @export
> >>>  methods::setAs( "BSgenome",
> >>>  "GRanges",
> >>>  function(from)  from %>%
> >>>  GenomeInfoDb::seqinfo() %>%
> >>>  as('GRanges'))
> >>>
> >>> Thankyou for feedback,
> >>>
> >>> Aditya
> >>>
> >>> 
> >>> From: Michael Lawrence [lawrence.mich...@gene.com]
> >>> Sent: Wednesday, September 11, 2019 2:31 PM
> >>> To: Bhagwat, Aditya
> >>> Cc: Pages, Herve; bioc-devel@r-project.org
> >>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching
> >>> BiocGenerics (and others)?
> >>>
> >>> I'm pretty surprised that the karyoploteR package does not accept a
> >>> Seqinfo since it is plotting chromosomes. But again, please consider
> >>> just doing as(seqinfo(bsgenome), "GRanges").
> >>>
> >>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
> >>>  wrote:
> >>>>
> >>>> Hi Herve,
> >>>>
> >>>> Thank you for your responses.
> >>>>  From your response, it is clear that the vcountPDict use case does
> >>>> not need a BSgenome -> GRanges coercer.
> >>>>
> >>>> The karyoploteR use case still requires it, though, to allow
> >>>> plotting of only the chromosomal BSgenome portions:
> >>>>
> >>>>  chromranges <- as(bsegenome, "GRanges")
> >>>>  kp <- karyoploteR::plotKaryotype(chromranges)
> >>>>  karyoploteR::kpPlotRegions(kp, crispr_target_sites)
> >>>>
> >>>> Or do you see any alternative for this purpose too?
> >>>>
> >>>> Aditya
> >>>>
> >>>> 
> >>>> From: Pages, Herve [hpa...@fredhutch.org]
> >>>> Sent: Wednesday, September 11, 2019 12:24 PM
> &g

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Pages, Herve
The unique seqnames is what we call the seqlevels. So just:

   as(seqinfo(bsgenome)[seqlevels(grl)], "GRanges")

H.

On 9/11/19 07:42, Michael Lawrence wrote:
> So why not just do:
> 
> as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")
> 
> Michael
> 
> On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
>  wrote:
>>
>> Thanks Michael,
>>
>> The important detail is that I want to plot the relevant chromosomes only
>>
>>  relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
>>  S4Vectors::runValue() %>%
>>  Reduce(union, .) %>%
>>  unique()
>>
>>  genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
>>  as('GRanges') %>%
>> (function(gr){
>> gr [ as.character(GenomeInfoDb::seqnames(gr)) %in%
>>  relevant_chromosomes ]
>> })
>>
>>  kp <- karyoploteR::plotKaryotype(genomeranges)
>>  karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist contains 
>> crispr target sites
>>
>>
>> And, this process required as("GRanges")
>>
>>  #' Convert BSgenome into GRanges
>>  #' @param from BSgenome, e.g. BSgenome.Mmusculus.UCSC.mm10::Mmusculus
>>  #' @examples
>>  #' require(magrittr)
>>  #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
>>  #' as('GRanges')
>>  #' @importClassesFrom BSgenome BSgenome
>>  #' @export
>>  methods::setAs( "BSgenome",
>>  "GRanges",
>>  function(from)  from %>%
>>  GenomeInfoDb::seqinfo() %>%
>>          as('GRanges'))
>>
>> Thankyou for feedback,
>>
>> Aditya
>>
>> 
>> From: Michael Lawrence [lawrence.mich...@gene.com]
>> Sent: Wednesday, September 11, 2019 2:31 PM
>> To: Bhagwat, Aditya
>> Cc: Pages, Herve; bioc-devel@r-project.org
>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>> BiocGenerics (and others)?
>>
>> I'm pretty surprised that the karyoploteR package does not accept a
>> Seqinfo since it is plotting chromosomes. But again, please consider
>> just doing as(seqinfo(bsgenome), "GRanges").
>>
>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>  wrote:
>>>
>>> Hi Herve,
>>>
>>> Thank you for your responses.
>>>  From your response, it is clear that the vcountPDict use case does not 
>>> need a BSgenome -> GRanges coercer.
>>>
>>> The karyoploteR use case still requires it, though, to allow plotting of 
>>> only the chromosomal BSgenome portions:
>>>
>>>  chromranges <- as(bsegenome, "GRanges")
>>>  kp <- karyoploteR::plotKaryotype(chromranges)
>>>  karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>
>>> Or do you see any alternative for this purpose too?
>>>
>>> Aditya
>>>
>>> 
>>> From: Pages, Herve [hpa...@fredhutch.org]
>>> Sent: Wednesday, September 11, 2019 12:24 PM
>>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>> BiocGenerics (and others)?
>>>
>>> Hi Aditya,
>>>
>>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>>> Hi Herve,
>>>>
>>>>
>>>>   > It feels that a coercion method from BSgenome to GRanges should
>>>> rather be defined in the BSgenome package itself.
>>>>
>>>> :-)
>>>>
>>>>
>>>>   > Patch/PR welcome on GitHub.
>>>>
>>>> Owkies. What pull/fork/check/branch protocol to be followed?
>>>>
>>>>
>>>>   > Is this what you have in mind for this coercion?
>>>>   > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>>>>
>>>> Yes.
>>>>
>>>> Perhaps also useful to share the wider context, allowing your and others
>>>> feedback for improved software design.
>>>> I wanted to subset a
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRA

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Pages, Herve
Or more accurately:

   as(seqinfo(bsgenome)[seqlevelsInUse(grl)], "GRanges")

since not all seqlevels are necessarily "in use" (i.e. not necessarily 
represented in seqnames(grl)).

H.

On 9/11/19 08:26, Hervé Pagès wrote:
> The unique seqnames is what we call the seqlevels. So just:
> 
>    as(seqinfo(bsgenome)[seqlevels(grl)], "GRanges")
> 
> H.
> 
> On 9/11/19 07:42, Michael Lawrence wrote:
>> So why not just do:
>>
>> as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")
>>
>> Michael
>>
>> On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
>>  wrote:
>>>
>>> Thanks Michael,
>>>
>>> The important detail is that I want to plot the relevant chromosomes 
>>> only
>>>
>>>  relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
>>>  S4Vectors::runValue() %>%
>>>  Reduce(union, .) %>%
>>>  unique()
>>>
>>>  genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
>>>  as('GRanges') %>%
>>>     (function(gr){
>>>     gr [ as.character(GenomeInfoDb::seqnames(gr)) 
>>> %in%
>>>  relevant_chromosomes ]
>>>     })
>>>
>>>  kp <- karyoploteR::plotKaryotype(genomeranges)
>>>  karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist 
>>> contains crispr target sites
>>>
>>>
>>> And, this process required as("GRanges")
>>>
>>>  #' Convert BSgenome into GRanges
>>>  #' @param from BSgenome, e.g. 
>>> BSgenome.Mmusculus.UCSC.mm10::Mmusculus
>>>  #' @examples
>>>  #' require(magrittr)
>>>  #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
>>>  #' as('GRanges')
>>>  #' @importClassesFrom BSgenome BSgenome
>>>  #' @export
>>>  methods::setAs( "BSgenome",
>>>              "GRanges",
>>>      function(from)  from %>%
>>>  GenomeInfoDb::seqinfo() %>%
>>>  as('GRanges'))
>>>
>>> Thankyou for feedback,
>>>
>>> Aditya
>>>
>>> 
>>> From: Michael Lawrence [lawrence.mich...@gene.com]
>>> Sent: Wednesday, September 11, 2019 2:31 PM
>>> To: Bhagwat, Aditya
>>> Cc: Pages, Herve; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>> BiocGenerics (and others)?
>>>
>>> I'm pretty surprised that the karyoploteR package does not accept a
>>> Seqinfo since it is plotting chromosomes. But again, please consider
>>> just doing as(seqinfo(bsgenome), "GRanges").
>>>
>>> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>>>  wrote:
>>>>
>>>> Hi Herve,
>>>>
>>>> Thank you for your responses.
>>>>  From your response, it is clear that the vcountPDict use case does 
>>>> not need a BSgenome -> GRanges coercer.
>>>>
>>>> The karyoploteR use case still requires it, though, to allow 
>>>> plotting of only the chromosomal BSgenome portions:
>>>>
>>>>  chromranges <- as(bsegenome, "GRanges")
>>>>  kp <- karyoploteR::plotKaryotype(chromranges)
>>>>  karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>>>>
>>>> Or do you see any alternative for this purpose too?
>>>>
>>>> Aditya
>>>>
>>>> 
>>>> From: Pages, Herve [hpa...@fredhutch.org]
>>>> Sent: Wednesday, September 11, 2019 12:24 PM
>>>> To: Bhagwat, Aditya; bioc-devel@r-project.org
>>>> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
>>>> BiocGenerics (and others)?
>>>>
>>>> Hi Aditya,
>>>>
>>>> On 9/11/19 01:31, Bhagwat, Aditya wrote:
>>>>> Hi Herve,
>>>>>
>>>>>
>>>>>   > It feels that a coercion method from BSgenome to GRanges should
>>>>> rather be defined in the BSgenome package itself.
>>>>>
>>>>> :-)
>>>>>
>>&

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Michael Lawrence via Bioc-devel
So why not just do:

as(seqinfo(bsgenome)[unique(unlist(seqnames(grl)))], "GRanges")

Michael

On Wed, Sep 11, 2019 at 5:55 AM Bhagwat, Aditya
 wrote:
>
> Thanks Michael,
>
> The important detail is that I want to plot the relevant chromosomes only
>
> relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>%
> S4Vectors::runValue() %>%
> Reduce(union, .) %>%
> unique()
>
> genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>%
> as('GRanges') %>%
>(function(gr){
>gr [ as.character(GenomeInfoDb::seqnames(gr)) %in%
> relevant_chromosomes ]
>})
>
> kp <- karyoploteR::plotKaryotype(genomeranges)
> karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist contains crispr 
> target sites
>
>
> And, this process required as("GRanges")
>
> #' Convert BSgenome into GRanges
> #' @param from BSgenome, e.g. BSgenome.Mmusculus.UCSC.mm10::Mmusculus
> #' @examples
> #' require(magrittr)
> #' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
> #' as('GRanges')
> #' @importClassesFrom BSgenome BSgenome
> #' @export
> methods::setAs( "BSgenome",
> "GRanges",
> function(from)  from %>%
> GenomeInfoDb::seqinfo() %>%
> as('GRanges'))
>
> Thankyou for feedback,
>
> Aditya
>
> ____________
> From: Michael Lawrence [lawrence.mich...@gene.com]
> Sent: Wednesday, September 11, 2019 2:31 PM
> To: Bhagwat, Aditya
> Cc: Pages, Herve; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> I'm pretty surprised that the karyoploteR package does not accept a
> Seqinfo since it is plotting chromosomes. But again, please consider
> just doing as(seqinfo(bsgenome), "GRanges").
>
> On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
>  wrote:
> >
> > Hi Herve,
> >
> > Thank you for your responses.
> > From your response, it is clear that the vcountPDict use case does not need 
> > a BSgenome -> GRanges coercer.
> >
> > The karyoploteR use case still requires it, though, to allow plotting of 
> > only the chromosomal BSgenome portions:
> >
> > chromranges <- as(bsegenome, "GRanges")
> > kp <- karyoploteR::plotKaryotype(chromranges)
> > karyoploteR::kpPlotRegions(kp, crispr_target_sites)
> >
> > Or do you see any alternative for this purpose too?
> >
> > Aditya
> >
> > 
> > From: Pages, Herve [hpa...@fredhutch.org]
> > Sent: Wednesday, September 11, 2019 12:24 PM
> > To: Bhagwat, Aditya; bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> > BiocGenerics (and others)?
> >
> > Hi Aditya,
> >
> > On 9/11/19 01:31, Bhagwat, Aditya wrote:
> > > Hi Herve,
> > >
> > >
> > >  > It feels that a coercion method from BSgenome to GRanges should
> > > rather be defined in the BSgenome package itself.
> > >
> > > :-)
> > >
> > >
> > >  > Patch/PR welcome on GitHub.
> > >
> > > Owkies. What pull/fork/check/branch protocol to be followed?
> > >
> > >
> > >  > Is this what you have in mind for this coercion?
> > >  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> > >
> > > Yes.
> > >
> > > Perhaps also useful to share the wider context, allowing your and others
> > > feedback for improved software design.
> > > I wanted to subset a
> > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
> > > (without the _random or _unassigned), but Lori explained this is not
> > > possible.
> > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
> > >
> > > Instead Lori sug

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Bhagwat, Aditya
Thanks Michael, 

The important detail is that I want to plot the relevant chromosomes only

relevant_chromosomes <- GenomeInfoDb::seqnames(grangeslist)  %>% 
S4Vectors::runValue() %>% 
Reduce(union, .) %>% 
unique()

genomeranges <- GenomeInfoDb::seqinfo(grangeslist) %>% 
as('GRanges') %>% 
   (function(gr){
   gr [ as.character(GenomeInfoDb::seqnames(gr)) %in% 
relevant_chromosomes ]
   })

kp <- karyoploteR::plotKaryotype(genomeranges)
karyoploteR::kpPlotRegions(kp, grangeslist) # grangeslist contains crispr 
target sites


And, this process required as("GRanges")

#' Convert BSgenome into GRanges 
#' @param from BSgenome, e.g. BSgenome.Mmusculus.UCSC.mm10::Mmusculus
#' @examples 
#' require(magrittr)
#' BSgenome.Mmusculus.UCSC.mm10::BSgenome.Mmusculus.UCSC.mm10 %>%
#' as('GRanges')
#' @importClassesFrom BSgenome BSgenome
#' @export
methods::setAs( "BSgenome", 
"GRanges", 
function(from)  from %>% 
GenomeInfoDb::seqinfo() %>% 
as('GRanges'))

Thankyou for feedback,

Aditya


From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Wednesday, September 11, 2019 2:31 PM
To: Bhagwat, Aditya
Cc: Pages, Herve; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

I'm pretty surprised that the karyoploteR package does not accept a
Seqinfo since it is plotting chromosomes. But again, please consider
just doing as(seqinfo(bsgenome), "GRanges").

On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
 wrote:
>
> Hi Herve,
>
> Thank you for your responses.
> From your response, it is clear that the vcountPDict use case does not need a 
> BSgenome -> GRanges coercer.
>
> The karyoploteR use case still requires it, though, to allow plotting of only 
> the chromosomal BSgenome portions:
>
> chromranges <- as(bsegenome, "GRanges")
> kp <- karyoploteR::plotKaryotype(chromranges)
> karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>
> Or do you see any alternative for this purpose too?
>
> Aditya
>
> 
> From: Pages, Herve [hpa...@fredhutch.org]
> Sent: Wednesday, September 11, 2019 12:24 PM
> To: Bhagwat, Aditya; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> Hi Aditya,
>
> On 9/11/19 01:31, Bhagwat, Aditya wrote:
> > Hi Herve,
> >
> >
> >  > It feels that a coercion method from BSgenome to GRanges should
> > rather be defined in the BSgenome package itself.
> >
> > :-)
> >
> >
> >  > Patch/PR welcome on GitHub.
> >
> > Owkies. What pull/fork/check/branch protocol to be followed?
> >
> >
> >  > Is this what you have in mind for this coercion?
> >  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> >
> > Yes.
> >
> > Perhaps also useful to share the wider context, allowing your and others
> > feedback for improved software design.
> > I wanted to subset a
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
> > (without the _random or _unassigned), but Lori explained this is not
> > possible.
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
> >
> > Instead Lori suggested to coerce a BSgenome into a GRanges
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_123489=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=6Eh73QthFfpPsfpRdPWs98pH6GHvv1Z23ORp34OCPxA=>,
> > which is a useful solution, but for which currently no exported S4
> > method exists
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124416=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=H8owJlOQrNHwNFHfCxGHe27Jxu6xjxpuAMWK8JlTU4Y=>
> > So I defin

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Michael Lawrence via Bioc-devel
I'm pretty surprised that the karyoploteR package does not accept a
Seqinfo since it is plotting chromosomes. But again, please consider
just doing as(seqinfo(bsgenome), "GRanges").

On Wed, Sep 11, 2019 at 3:59 AM Bhagwat, Aditya
 wrote:
>
> Hi Herve,
>
> Thank you for your responses.
> From your response, it is clear that the vcountPDict use case does not need a 
> BSgenome -> GRanges coercer.
>
> The karyoploteR use case still requires it, though, to allow plotting of only 
> the chromosomal BSgenome portions:
>
> chromranges <- as(bsegenome, "GRanges")
> kp <- karyoploteR::plotKaryotype(chromranges)
> karyoploteR::kpPlotRegions(kp, crispr_target_sites)
>
> Or do you see any alternative for this purpose too?
>
> Aditya
>
> 
> From: Pages, Herve [hpa...@fredhutch.org]
> Sent: Wednesday, September 11, 2019 12:24 PM
> To: Bhagwat, Aditya; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> Hi Aditya,
>
> On 9/11/19 01:31, Bhagwat, Aditya wrote:
> > Hi Herve,
> >
> >
> >  > It feels that a coercion method from BSgenome to GRanges should
> > rather be defined in the BSgenome package itself.
> >
> > :-)
> >
> >
> >  > Patch/PR welcome on GitHub.
> >
> > Owkies. What pull/fork/check/branch protocol to be followed?
> >
> >
> >  > Is this what you have in mind for this coercion?
> >  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> >
> > Yes.
> >
> > Perhaps also useful to share the wider context, allowing your and others
> > feedback for improved software design.
> > I wanted to subset a
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
> > (without the _random or _unassigned), but Lori explained this is not
> > possible.
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
> >
> > Instead Lori suggested to coerce a BSgenome into a GRanges
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_123489=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=6Eh73QthFfpPsfpRdPWs98pH6GHvv1Z23ORp34OCPxA=>,
> > which is a useful solution, but for which currently no exported S4
> > method exists
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124416=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=H8owJlOQrNHwNFHfCxGHe27Jxu6xjxpuAMWK8JlTU4Y=>
> > So I defined an S4 coercer in my multicrispr package, making sure to
> > properly import the Bsgenome class
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124442=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=2XNBVcwoJTjlxY_gl4UPzrHPKmKH9LTnM4ih5SQOfps=>.
> > Then, after coercing a BSgenome into a GRanges, I can extract the
> > chromosomes, after properly importing IRanges::`%in%`
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
>
> Looks like you don't need to coerce the BSgenome object to GRanges. See
> https://support.bioconductor.org/p/123489/#124581
>
> H.
>
> > Which I can then on end to karyoploteR
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124328=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=M90_rBO1oohGnXe2XBpQHQriFNthY_W0hzN6KWlf2S4=>,
> > for genome-wide plots of crispr target sites.
> >
> > A good moment also to say thank you to all of you who helped me out, it
> > helps me to make multicrispr fit nicely into the BioC ecosystem.
> >
> > Speeking of BioC design philosophy, can any of you suggest concise and
> > to-the-point reading material to deepen my understanding of the core

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Bhagwat, Aditya
Hi Herve,

Thank you for your responses. 
>From your response, it is clear that the vcountPDict use case does not need a 
>BSgenome -> GRanges coercer.

The karyoploteR use case still requires it, though, to allow plotting of only 
the chromosomal BSgenome portions:

chromranges <- as(bsegenome, "GRanges")
kp <- karyoploteR::plotKaryotype(chromranges)
karyoploteR::kpPlotRegions(kp, crispr_target_sites)

Or do you see any alternative for this purpose too?

Aditya


From: Pages, Herve [hpa...@fredhutch.org]
Sent: Wednesday, September 11, 2019 12:24 PM
To: Bhagwat, Aditya; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

Hi Aditya,

On 9/11/19 01:31, Bhagwat, Aditya wrote:
> Hi Herve,
>
>
>  > It feels that a coercion method from BSgenome to GRanges should
> rather be defined in the BSgenome package itself.
>
> :-)
>
>
>  > Patch/PR welcome on GitHub.
>
> Owkies. What pull/fork/check/branch protocol to be followed?
>
>
>  > Is this what you have in mind for this coercion?
>  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
>
> Yes.
>
> Perhaps also useful to share the wider context, allowing your and others
> feedback for improved software design.
> I wanted to subset a
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
> (without the _random or _unassigned), but Lori explained this is not
> possible.
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
>
> Instead Lori suggested to coerce a BSgenome into a GRanges
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_123489=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=6Eh73QthFfpPsfpRdPWs98pH6GHvv1Z23ORp34OCPxA=>,
> which is a useful solution, but for which currently no exported S4
> method exists
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124416=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=H8owJlOQrNHwNFHfCxGHe27Jxu6xjxpuAMWK8JlTU4Y=>
> So I defined an S4 coercer in my multicrispr package, making sure to
> properly import the Bsgenome class
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124442=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=2XNBVcwoJTjlxY_gl4UPzrHPKmKH9LTnM4ih5SQOfps=>.
> Then, after coercing a BSgenome into a GRanges, I can extract the
> chromosomes, after properly importing IRanges::`%in%`
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>

Looks like you don't need to coerce the BSgenome object to GRanges. See
https://support.bioconductor.org/p/123489/#124581

H.

> Which I can then on end to karyoploteR
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124328=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=M90_rBO1oohGnXe2XBpQHQriFNthY_W0hzN6KWlf2S4=>,
> for genome-wide plots of crispr target sites.
>
> A good moment also to say thank you to all of you who helped me out, it
> helps me to make multicrispr fit nicely into the BioC ecosystem.
>
> Speeking of BioC design philosophy, can any of you suggest concise and
> to-the-point reading material to deepen my understanding of the core
> BioC software design philosophy?
> I am trying to understand that better (which was the context for asking
> recently why there are three Vector -> data.frame coercers in S4Vectors
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124491=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=nBHdQoTrd1Mfu4VTMgtkPyUQ0Ju2NLeX-0X1Ny3fSeg=>)
>
> Cheers,
>
> Aditya
>
>
>
>
> 
> From: Pages, Herve [hpa...@fredhutch.org]
> Sent: Tuesday, September 10, 2019 6:45 PM
> To: Bhagwat, Aditya; bioc-devel@r-pro

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Pages, Herve
Hi Aditya,

On 9/11/19 01:31, Bhagwat, Aditya wrote:
> Hi Herve,
> 
> 
>  > It feels that a coercion method from BSgenome to GRanges should 
> rather be defined in the BSgenome package itself.
> 
> :-)
> 
> 
>  > Patch/PR welcome on GitHub.
> 
> Owkies. What pull/fork/check/branch protocol to be followed?
> 
> 
>  > Is this what you have in mind for this coercion?
>  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> 
> Yes.
> 
> Perhaps also useful to share the wider context, allowing your and others 
> feedback for improved software design.
> I wanted to subset a 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>BSgenome
>  
> (without the _random or _unassigned), but Lori explained this is not 
> possible. 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>
>  
> 
> Instead Lori suggested to coerce a BSgenome into a GRanges 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_123489=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=6Eh73QthFfpPsfpRdPWs98pH6GHvv1Z23ORp34OCPxA=>,
>  
> which is a useful solution, but for which currently no exported S4 
> method exists 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124416=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=H8owJlOQrNHwNFHfCxGHe27Jxu6xjxpuAMWK8JlTU4Y=>
> So I defined an S4 coercer in my multicrispr package, making sure to 
> properly import the Bsgenome class 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124442=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=2XNBVcwoJTjlxY_gl4UPzrHPKmKH9LTnM4ih5SQOfps=>.
> Then, after coercing a BSgenome into a GRanges, I can extract the 
> chromosomes, after properly importing IRanges::`%in%` 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124367=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=xNa-6ZKTD1MnnfT55tntHjdK51Y1JQGQxTlzX2-OYmI=>

Looks like you don't need to coerce the BSgenome object to GRanges. See 
https://support.bioconductor.org/p/123489/#124581

H.

> Which I can then on end to karyoploteR 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124328=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=M90_rBO1oohGnXe2XBpQHQriFNthY_W0hzN6KWlf2S4=>,
>  
> for genome-wide plots of crispr target sites.
> 
> A good moment also to say thank you to all of you who helped me out, it 
> helps me to make multicrispr fit nicely into the BioC ecosystem.
> 
> Speeking of BioC design philosophy, can any of you suggest concise and 
> to-the-point reading material to deepen my understanding of the core 
> BioC software design philosophy?
> I am trying to understand that better (which was the context for asking 
> recently why there are three Vector -> data.frame coercers in S4Vectors 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124491=DwMFAw=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=FGFwBT0tJu3lfRS_rafeatLzrPxK7PEM0aanQY4M6wY=nBHdQoTrd1Mfu4VTMgtkPyUQ0Ju2NLeX-0X1Ny3fSeg=>)
> 
> Cheers,
> 
> Aditya
> 
> 
> 
> 
> ____
> From: Pages, Herve [hpa...@fredhutch.org]
> Sent: Tuesday, September 10, 2019 6:45 PM
> To: Bhagwat, Aditya; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
> 
> Hi Aditya,
> 
> 
> More generally speaking, coercion methods should be defined in a place
> that is "as close as possible" to the "from" or "to" classes rather than
> in a package that doesn't own any of the 2 classes involved.
> Is this what you have in mind for this coercion?
> 
>  > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
> GRanges object with 7 ranges and 0 metadata columns:
> seqnames ranges strand
>   
> chrI chrI 1-15072423 *
> chrII chrII 1-15279345 *
> chrIII chrIII 1-1378

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-11 Thread Bhagwat, Aditya
Hi Herve,


> It feels that a coercion method from BSgenome to GRanges should rather be 
> defined in the BSgenome package itself.

:-)


> Patch/PR welcome on GitHub.

Owkies. What pull/fork/check/branch protocol to be followed?


> Is this what you have in mind for this coercion?
> as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")

Yes.

Perhaps also useful to share the wider context, allowing your and others 
feedback for improved software design.
I wanted to subset a <https://support.bioconductor.org/p/124367> BSgenome 
(without the _random or _unassigned), but Lori explained this is not 
possible.<https://support.bioconductor.org/p/124367>
Instead Lori suggested to coerce a BSgenome into a 
GRanges<https://support.bioconductor.org/p/123489>, which is a useful solution, 
but for which currently no exported S4 method 
exists<https://support.bioconductor.org/p/124416>
So I defined an S4 coercer in my multicrispr package, making sure to properly 
import the Bsgenome class<https://support.bioconductor.org/p/124442>.
Then, after coercing a BSgenome into a GRanges, I can extract the chromosomes, 
after properly importing 
IRanges::`%in%`<https://support.bioconductor.org/p/124367>
Which I can then on end to 
karyoploteR<https://support.bioconductor.org/p/124328>, for genome-wide plots 
of crispr target sites.

A good moment also to say thank you to all of you who helped me out, it helps 
me to make multicrispr fit nicely into the BioC ecosystem.

Speeking of BioC design philosophy, can any of you suggest concise and 
to-the-point reading material to deepen my understanding of the core BioC 
software design philosophy?
I am trying to understand that better (which was the context for asking 
recently why there are three Vector -> data.frame coercers in 
S4Vectors<https://support.bioconductor.org/p/124491>)

Cheers,

Aditya





From: Pages, Herve [hpa...@fredhutch.org]
Sent: Tuesday, September 10, 2019 6:45 PM
To: Bhagwat, Aditya; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

Hi Aditya,


More generally speaking, coercion methods should be defined in a place
that is "as close as possible" to the "from" or "to" classes rather than
in a package that doesn't own any of the 2 classes involved.
Is this what you have in mind for this coercion?

> as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
GRanges object with 7 ranges and 0 metadata columns:
seqnames ranges strand
  
chrI chrI 1-15072423 *
chrII chrII 1-15279345 *
chrIII chrIII 1-13783700 *
chrIV chrIV 1-17493793 *
chrV chrV 1-20924149 *
chrX chrX 1-17718866 *
chrM chrM 1-13794 *
---
seqinfo: 7 sequences (1 circular) from ce10 genome

Thanks,
H.


On 9/6/19 03:39, Bhagwat, Aditya wrote:
> Dear Bioc devel,
>
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr<https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.gwdg.de_loosolab_software_multicrispr=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cXJaaEvfNbOioopXgFWQms1qny1xehFQyb3V3xDy55M=MIR-kUeXy9oWokdQxItuG82hrvs0uwP1aBIqNdM-Jrs=
>  >).
>
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> (Posted earlier on BioC 
> support<https://urldefense.proofpoint.com/v2/url?u=https-3A__support.bioconductor.org_p_124442_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cXJaaEvfNbOioopXgFWQms1qny1xehFQyb3V3xDy55M=oBSScH5uD5j0vCAaj4dfWepjiNGtHm9q5gA8eaIudZ4=
>  > and redirected here following Martin's suggestion)
>
> Thankyou :-)
>
> Aditya
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cXJaaEvfNbOioopXgFWQms1qny1xehFQyb3V3xDy55M=cEojiObibdSuzmh21opvy85DZyRrjtfo1vEMopKWmAg=
>

--
Herv� Pag�s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-10 Thread Pages, Herve
Hi Aditya,

It feels that a coercion method from BSgenome to GRanges should rather 
be defined in the BSgenome package itself. Patch/PR welcome on GitHub. 
More generally speaking, coercion methods should be defined in a place 
that is "as close as possible" to the "from" or "to" classes rather than 
in a package that doesn't own any of the 2 classes involved.

Is this what you have in mind for this coercion?

   > as(seqinfo(BSgenome.Celegans.UCSC.ce10), "GRanges")
   GRanges object with 7 ranges and 0 metadata columns:
seqnames ranges strand
   
   chrI chrI 1-15072423  *
  chrIIchrII 1-15279345  *
 chrIII   chrIII 1-13783700  *
  chrIVchrIV 1-17493793  *
   chrV chrV 1-20924149  *
   chrX chrX 1-17718866  *
   chrM chrM1-13794  *
 ---
 seqinfo: 7 sequences (1 circular) from ce10 genome

Thanks,
H.


On 9/6/19 03:39, Bhagwat, Aditya wrote:
> Dear Bioc devel,
> 
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr  >).
> 
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> 
> (Posted earlier on BioC 
> support  > and redirected here following Martin's suggestion)
> 
> Thankyou :-)
> 
> Aditya
> 
>   [[alternative HTML version deleted]]
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=cXJaaEvfNbOioopXgFWQms1qny1xehFQyb3V3xDy55M=cEojiObibdSuzmh21opvy85DZyRrjtfo1vEMopKWmAg=
> 

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-06 Thread Bhagwat, Aditya
Waaw, thanks Michael, that is really clarifying. 


From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Friday, September 06, 2019 7:32 PM
To: Bhagwat, Aditya
Cc: Kasper Daniel Hansen; Michael Lawrence; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

There's never a need to attach a package to satisfy the dependencies
of another package. That would defeat the purpose of namespaces.

The three coercion functions gets at the heart of the S3/S4 mess.
setAs() provides a dynamic coercion mechanism, so is useful for as(x,
class) when class can be anything. as.data.frame() is an S3 generic
defined by the base package, so every package sees it. Something
promotes as.data.frame() to an S4 generic, but only packages that
import the generic can see it. That likely excludes the vast majority
of CRAN packages. Thus, we define an S3 method for calls to the S3
generic. The S4 generic will fall back to the S3 methods; however, it
will first check all S4 methods. Defining as.data.frame,Vector()
defends against the definition of a method above it, such as
as.data.frame,Annotated(), which would intercept dispatch to the S3
as.data.frame.Vector().

Michael

On Fri, Sep 6, 2019 at 10:08 AM Bhagwat, Aditya
 wrote:
>
> Thanks Kasper and Michael.
>
>
>
> The importClassesFrom  sounds like something that would allow an 
> attachment-free S4 class import, will check them out.
>
> Michael, the current auto-attach is causing 66 namespace clashes – not 
> feeling very comfortable about that, so trying to avoid them.
>
>
>
> I also think there’s something about S4 coercion that I don’t yet fully 
> understand.
>
> For instance: the S4Vectors package has three different versions of a 
> S4Vectors::Vector -> data.frame coercer. Why? Any useful pointers?
>
>
>
> setAs("Vector", "data.frame", function(from) as.data.frame(from))
>
>
>
> as.data.frame.Vector <- function(x, row.names=NULL, optional=FALSE, ...) {
>
> as.data.frame(x, row.names=NULL, optional=optional, ...)
>
> }
>
>
>
> setMethod("as.data.frame", "Vector",
>
>   function(x, row.names=NULL, optional=FALSE, ...)
>
>   {
>
>   x <- as.vector(x)
>
>   as.data.frame(x, row.names=row.names, optional=optional, ...)
>
>       })
>
>
>
>
>
>
>
> From: Kasper Daniel Hansen 
> Sent: Freitag, 6. September 2019 17:49
> To: Michael Lawrence 
> Cc: Bhagwat, Aditya ; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
>
>
> There are
>
>   importMethodsFrom(PACKAGE, NAME_OF_METHODS)
>
>   importClassesFrom(PACKAGE, NAME_OF_METHODS)
>
> to help with selective importing S4 methods/classes.  See section 1.5.6 of 
> WRE.
>
>
>
> On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel 
>  wrote:
>
> It sounds like you are trying to defer loading of namespaces in order
> to save time when they are unnecessary? That's probably going to end
> up a losing battle.
>
> On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
>  wrote:
> >
> > Thank you Michael,
> >
> > Appreciate your time for helping me fill the gaps in my understanding of 
> > the S4 flow :-).
> >
> > It all started when I defined (in my multicrispr package) the S4 coercer :
> > methods::setAs( "BSgenome",
> >
> > "GRanges",
> > function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
> >
> > When building, I noticed the message
> > in method for 'coerce' with signature '"BSgenome","GRanges"': no definition 
> > for class "BSgenome"
> >
> > So, I added
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > That loads all these dependencies.
> > From your answer, I understand that there is currently no alternative to 
> > loading all these dependencies.
> > I guess because these dependencies are needed to provide for all required 
> > S4 methods for the BSgenome class, am I right?
> >
> > Is there a way to define a methods::setAs without loading the class 
> > definition?
> >
> > Aditya
> >
> >
> >
> >
> > 
> > From: Michael Lawrence [lawrence.mich...@gene.com]
> > Sent: Friday, September 06, 2019 1:09 PM
> > To: Bhagwat, Aditya
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> > BiocGenerics 

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-06 Thread Michael Lawrence via Bioc-devel
There's never a need to attach a package to satisfy the dependencies
of another package. That would defeat the purpose of namespaces.

The three coercion functions gets at the heart of the S3/S4 mess.
setAs() provides a dynamic coercion mechanism, so is useful for as(x,
class) when class can be anything. as.data.frame() is an S3 generic
defined by the base package, so every package sees it. Something
promotes as.data.frame() to an S4 generic, but only packages that
import the generic can see it. That likely excludes the vast majority
of CRAN packages. Thus, we define an S3 method for calls to the S3
generic. The S4 generic will fall back to the S3 methods; however, it
will first check all S4 methods. Defining as.data.frame,Vector()
defends against the definition of a method above it, such as
as.data.frame,Annotated(), which would intercept dispatch to the S3
as.data.frame.Vector().

Michael

On Fri, Sep 6, 2019 at 10:08 AM Bhagwat, Aditya
 wrote:
>
> Thanks Kasper and Michael.
>
>
>
> The importClassesFrom  sounds like something that would allow an 
> attachment-free S4 class import, will check them out.
>
> Michael, the current auto-attach is causing 66 namespace clashes – not 
> feeling very comfortable about that, so trying to avoid them.
>
>
>
> I also think there’s something about S4 coercion that I don’t yet fully 
> understand.
>
> For instance: the S4Vectors package has three different versions of a 
> S4Vectors::Vector -> data.frame coercer. Why? Any useful pointers?
>
>
>
> setAs("Vector", "data.frame", function(from) as.data.frame(from))
>
>
>
> as.data.frame.Vector <- function(x, row.names=NULL, optional=FALSE, ...) {
>
> as.data.frame(x, row.names=NULL, optional=optional, ...)
>
> }
>
>
>
> setMethod("as.data.frame", "Vector",
>
>   function(x, row.names=NULL, optional=FALSE, ...)
>
>   {
>
>   x <- as.vector(x)
>
>   as.data.frame(x, row.names=row.names, optional=optional, ...)
>
>       })
>
>
>
>
>
>
>
> From: Kasper Daniel Hansen 
> Sent: Freitag, 6. September 2019 17:49
> To: Michael Lawrence 
> Cc: Bhagwat, Aditya ; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
>
>
> There are
>
>   importMethodsFrom(PACKAGE, NAME_OF_METHODS)
>
>   importClassesFrom(PACKAGE, NAME_OF_METHODS)
>
> to help with selective importing S4 methods/classes.  See section 1.5.6 of 
> WRE.
>
>
>
> On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel 
>  wrote:
>
> It sounds like you are trying to defer loading of namespaces in order
> to save time when they are unnecessary? That's probably going to end
> up a losing battle.
>
> On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
>  wrote:
> >
> > Thank you Michael,
> >
> > Appreciate your time for helping me fill the gaps in my understanding of 
> > the S4 flow :-).
> >
> > It all started when I defined (in my multicrispr package) the S4 coercer :
> > methods::setAs( "BSgenome",
> >
> > "GRanges",
> > function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
> >
> > When building, I noticed the message
> > in method for 'coerce' with signature '"BSgenome","GRanges"': no definition 
> > for class "BSgenome"
> >
> > So, I added
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > That loads all these dependencies.
> > From your answer, I understand that there is currently no alternative to 
> > loading all these dependencies.
> > I guess because these dependencies are needed to provide for all required 
> > S4 methods for the BSgenome class, am I right?
> >
> > Is there a way to define a methods::setAs without loading the class 
> > definition?
> >
> > Aditya
> >
> >
> >
> >
> > 
> > From: Michael Lawrence [lawrence.mich...@gene.com]
> > Sent: Friday, September 06, 2019 1:09 PM
> > To: Bhagwat, Aditya
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> > BiocGenerics (and others)?
> >
> > The way to keep a "clean namespace" is to selectively import symbols
> > into your namespace, not to import _nothing_ into your namespace.
> > Otherwise, your code will fill with namespace qualifications that
> > distract from what is more important to communicate: the intent of the
> > code. And no, there's

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-06 Thread Bhagwat, Aditya
Thanks Kasper and Michael.

The importClassesFrom  sounds like something that would allow an 
attachment-free S4 class import, will check them out.
Michael, the current auto-attach is causing 66 namespace 
clashes<https://support.bioconductor.org/p/124442/> – not feeling very 
comfortable about that, so trying to avoid them.

I also think there’s something about S4 coercion that I don’t yet fully 
understand.
For instance: the S4Vectors package has three different versions of a 
S4Vectors::Vector -> data.frame coercer. Why? Any useful pointers?

setAs("Vector", "data.frame", function(from) as.data.frame(from))

as.data.frame.Vector <- function(x, row.names=NULL, optional=FALSE, ...) {
as.data.frame(x, row.names=NULL, optional=optional, ...)
}

setMethod("as.data.frame", "Vector",
  function(x, row.names=NULL, optional=FALSE, ...)
  {
  x <- as.vector(x)
  as.data.frame(x, row.names=row.names, optional=optional, ...)
  })



From: Kasper Daniel Hansen 
Sent: Freitag, 6. September 2019 17:49
To: Michael Lawrence 
Cc: Bhagwat, Aditya ; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

There are
  importMethodsFrom(PACKAGE, NAME_OF_METHODS)
  importClassesFrom(PACKAGE, NAME_OF_METHODS)
to help with selective importing S4 methods/classes.  See section 1.5.6 of WRE.

On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel 
mailto:bioc-devel@r-project.org>> wrote:
It sounds like you are trying to defer loading of namespaces in order
to save time when they are unnecessary? That's probably going to end
up a losing battle.

On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
mailto:aditya.bhag...@mpi-bn.mpg.de>> wrote:
>
> Thank you Michael,
>
> Appreciate your time for helping me fill the gaps in my understanding of the 
> S4 flow :-).
>
> It all started when I defined (in my multicrispr package) the S4 coercer :
> methods::setAs( "BSgenome",
>
> "GRanges",
> function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
>
> When building, I noticed the message
> in method for 'coerce' with signature '"BSgenome","GRanges"': no definition 
> for class "BSgenome"
>
> So, I added
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> That loads all these dependencies.
> From your answer, I understand that there is currently no alternative to 
> loading all these dependencies.
> I guess because these dependencies are needed to provide for all required S4 
> methods for the BSgenome class, am I right?
>
> Is there a way to define a methods::setAs without loading the class 
> definition?
>
> Aditya
>
>
>
>
> ____
> From: Michael Lawrence 
> [lawrence.mich...@gene.com<mailto:lawrence.mich...@gene.com>]
> Sent: Friday, September 06, 2019 1:09 PM
> To: Bhagwat, Aditya
> Cc: bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> The way to keep a "clean namespace" is to selectively import symbols
> into your namespace, not to import _nothing_ into your namespace.
> Otherwise, your code will fill with namespace qualifications that
> distract from what is more important to communicate: the intent of the
> code. And no, there's no way to define method signatures using
> anything other than simple class names.
>
> It would be interesting to explore alternative ways of specifying
> method signatures. One way would be if every package exported a "class
> reference" (class name with package attribute, at least) for each of
> its classes. Those could be treated like any other exported object,
> and referenced via namespace qualification. It would require major
> changes to the methods package but that should probably happen anyway
> to support disambiguation when two packages define a class of the same
> name. It would be nice to get away from the exportClasses() and
> importClasses() stuff. File that under the "rainy year" category.
>
> Michael
>
> On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
> mailto:aditya.bhag...@mpi-bn.mpg.de>> wrote:
> >
> > Dear Bioc devel,
> >
> > Is it possible to import the BSgenome class without attaching BiocGenerics 
> > (to keep a clean namespace during the development of 
> > multicrispr<https://gitlab.gwdg.de/loosolab/software/multicrispr>).
> >
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > (Posted earlier on BioC support<https://support.bioconductor.or

Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-06 Thread Kasper Daniel Hansen
There are
  importMethodsFrom(PACKAGE, NAME_OF_METHODS)
  importClassesFrom(PACKAGE, NAME_OF_METHODS)
to help with selective importing S4 methods/classes.  See section 1.5.6 of
WRE.

On Fri, Sep 6, 2019 at 9:24 AM Michael Lawrence via Bioc-devel <
bioc-devel@r-project.org> wrote:

> It sounds like you are trying to defer loading of namespaces in order
> to save time when they are unnecessary? That's probably going to end
> up a losing battle.
>
> On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
>  wrote:
> >
> > Thank you Michael,
> >
> > Appreciate your time for helping me fill the gaps in my understanding of
> the S4 flow :-).
> >
> > It all started when I defined (in my multicrispr package) the S4 coercer
> :
> > methods::setAs( "BSgenome",
> >
> > "GRanges",
> > function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
> >
> > When building, I noticed the message
> > in method for 'coerce' with signature '"BSgenome","GRanges"': no
> definition for class "BSgenome"
> >
> > So, I added
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > That loads all these dependencies.
> > From your answer, I understand that there is currently no alternative to
> loading all these dependencies.
> > I guess because these dependencies are needed to provide for all
> required S4 methods for the BSgenome class, am I right?
> >
> > Is there a way to define a methods::setAs without loading the class
> definition?
> >
> > Aditya
> >
> >
> >
> >
> > ________
> > From: Michael Lawrence [lawrence.mich...@gene.com]
> > Sent: Friday, September 06, 2019 1:09 PM
> > To: Bhagwat, Aditya
> > Cc: bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] Import BSgenome class without attaching
> BiocGenerics (and others)?
> >
> > The way to keep a "clean namespace" is to selectively import symbols
> > into your namespace, not to import _nothing_ into your namespace.
> > Otherwise, your code will fill with namespace qualifications that
> > distract from what is more important to communicate: the intent of the
> > code. And no, there's no way to define method signatures using
> > anything other than simple class names.
> >
> > It would be interesting to explore alternative ways of specifying
> > method signatures. One way would be if every package exported a "class
> > reference" (class name with package attribute, at least) for each of
> > its classes. Those could be treated like any other exported object,
> > and referenced via namespace qualification. It would require major
> > changes to the methods package but that should probably happen anyway
> > to support disambiguation when two packages define a class of the same
> > name. It would be nice to get away from the exportClasses() and
> > importClasses() stuff. File that under the "rainy year" category.
> >
> > Michael
> >
> > On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
> >  wrote:
> > >
> > > Dear Bioc devel,
> > >
> > > Is it possible to import the BSgenome class without attaching
> BiocGenerics (to keep a clean namespace during the development of
> multicrispr<https://gitlab.gwdg.de/loosolab/software/multicrispr>).
> > >
> > > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> > >
> > > (Posted earlier on BioC support<
> https://support.bioconductor.org/p/124442/> and redirected here following
> Martin's suggestion)
> > >
> > > Thankyou :-)
> > >
> > > Aditya
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> >
> >
> > --
> > Michael Lawrence
> > Scientist, Bioinformatics and Computational Biology
> > Genentech, A Member of the Roche Group
> > Office +1 (650) 225-7760
> > micha...@gene.com
> >
> > Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
>
>
>
> --
> Michael Lawrence
> Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the Roche Group
> Office +1 (650) 225-7760
> micha...@gene.com
>
> Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-06 Thread Michael Lawrence via Bioc-devel
It sounds like you are trying to defer loading of namespaces in order
to save time when they are unnecessary? That's probably going to end
up a losing battle.

On Fri, Sep 6, 2019 at 5:47 AM Bhagwat, Aditya
 wrote:
>
> Thank you Michael,
>
> Appreciate your time for helping me fill the gaps in my understanding of the 
> S4 flow :-).
>
> It all started when I defined (in my multicrispr package) the S4 coercer :
> methods::setAs( "BSgenome",
>
> "GRanges",
> function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")
>
> When building, I noticed the message
> in method for 'coerce' with signature '"BSgenome","GRanges"': no definition 
> for class "BSgenome"
>
> So, I added
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> That loads all these dependencies.
> From your answer, I understand that there is currently no alternative to 
> loading all these dependencies.
> I guess because these dependencies are needed to provide for all required S4 
> methods for the BSgenome class, am I right?
>
> Is there a way to define a methods::setAs without loading the class 
> definition?
>
> Aditya
>
>
>
>
> ____
> From: Michael Lawrence [lawrence.mich...@gene.com]
> Sent: Friday, September 06, 2019 1:09 PM
> To: Bhagwat, Aditya
> Cc: bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Import BSgenome class without attaching 
> BiocGenerics (and others)?
>
> The way to keep a "clean namespace" is to selectively import symbols
> into your namespace, not to import _nothing_ into your namespace.
> Otherwise, your code will fill with namespace qualifications that
> distract from what is more important to communicate: the intent of the
> code. And no, there's no way to define method signatures using
> anything other than simple class names.
>
> It would be interesting to explore alternative ways of specifying
> method signatures. One way would be if every package exported a "class
> reference" (class name with package attribute, at least) for each of
> its classes. Those could be treated like any other exported object,
> and referenced via namespace qualification. It would require major
> changes to the methods package but that should probably happen anyway
> to support disambiguation when two packages define a class of the same
> name. It would be nice to get away from the exportClasses() and
> importClasses() stuff. File that under the "rainy year" category.
>
> Michael
>
> On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
>  wrote:
> >
> > Dear Bioc devel,
> >
> > Is it possible to import the BSgenome class without attaching BiocGenerics 
> > (to keep a clean namespace during the development of 
> > multicrispr<https://gitlab.gwdg.de/loosolab/software/multicrispr>).
> >
> > BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
> >
> > (Posted earlier on BioC support<https://support.bioconductor.org/p/124442/> 
> > and redirected here following Martin's suggestion)
> >
> > Thankyou :-)
> >
> > Aditya
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>
> --
> Michael Lawrence
> Scientist, Bioinformatics and Computational Biology
> Genentech, A Member of the Roche Group
> Office +1 (650) 225-7760
> micha...@gene.com
>
> Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-06 Thread Bhagwat, Aditya
I noticed the unfriendly indentation and formatting of my response , so I 
updated my original question on BioC support (with a much more eye-friendly 
formatting):

https://support.bioconductor.org/p/124442



From: Bhagwat, Aditya
Sent: Friday, September 06, 2019 2:47 PM
To: Michael Lawrence
Cc: bioc-devel@r-project.org
Subject: RE: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

Thank you Michael,

Appreciate your time for helping me fill the gaps in my understanding of the S4 
flow :-).

It all started when I defined (in my multicrispr package) the S4 coercer :
methods::setAs( "BSgenome",
"GRanges",
function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")

When building, I noticed the message
in method for 'coerce' with signature '"BSgenome","GRanges"': no definition for 
class "BSgenome"

So, I added
BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')

That loads all these dependencies.
>From your answer, I understand that there is currently no alternative to 
>loading all these dependencies.
I guess because these dependencies are needed to provide for all required S4 
methods for the BSgenome class, am I right?

Is there a way to define a methods::setAs without loading the class definition?

Aditya





From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Friday, September 06, 2019 1:09 PM
To: Bhagwat, Aditya
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

The way to keep a "clean namespace" is to selectively import symbols
into your namespace, not to import _nothing_ into your namespace.
Otherwise, your code will fill with namespace qualifications that
distract from what is more important to communicate: the intent of the
code. And no, there's no way to define method signatures using
anything other than simple class names.

It would be interesting to explore alternative ways of specifying
method signatures. One way would be if every package exported a "class
reference" (class name with package attribute, at least) for each of
its classes. Those could be treated like any other exported object,
and referenced via namespace qualification. It would require major
changes to the methods package but that should probably happen anyway
to support disambiguation when two packages define a class of the same
name. It would be nice to get away from the exportClasses() and
importClasses() stuff. File that under the "rainy year" category.

Michael

On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
 wrote:
>
> Dear Bioc devel,
>
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr<https://gitlab.gwdg.de/loosolab/software/multicrispr>).
>
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> (Posted earlier on BioC support<https://support.bioconductor.org/p/124442/> 
> and redirected here following Martin's suggestion)
>
> Thankyou :-)
>
> Aditya
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-06 Thread Bhagwat, Aditya
Thank you Michael,

Appreciate your time for helping me fill the gaps in my understanding of the S4 
flow :-).

It all started when I defined (in my multicrispr package) the S4 coercer :
methods::setAs( "BSgenome",
"GRanges",
function(from) as(GenomeInfoDb::seqinfo(from), "GRanges")

When building, I noticed the message
in method for 'coerce' with signature '"BSgenome","GRanges"': no definition for 
class "BSgenome"

So, I added
BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')

That loads all these dependencies.
>From your answer, I understand that there is currently no alternative to 
>loading all these dependencies.
I guess because these dependencies are needed to provide for all required S4 
methods for the BSgenome class, am I right?

Is there a way to define a methods::setAs without loading the class definition?

Aditya





From: Michael Lawrence [lawrence.mich...@gene.com]
Sent: Friday, September 06, 2019 1:09 PM
To: Bhagwat, Aditya
Cc: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics 
(and others)?

The way to keep a "clean namespace" is to selectively import symbols
into your namespace, not to import _nothing_ into your namespace.
Otherwise, your code will fill with namespace qualifications that
distract from what is more important to communicate: the intent of the
code. And no, there's no way to define method signatures using
anything other than simple class names.

It would be interesting to explore alternative ways of specifying
method signatures. One way would be if every package exported a "class
reference" (class name with package attribute, at least) for each of
its classes. Those could be treated like any other exported object,
and referenced via namespace qualification. It would require major
changes to the methods package but that should probably happen anyway
to support disambiguation when two packages define a class of the same
name. It would be nice to get away from the exportClasses() and
importClasses() stuff. File that under the "rainy year" category.

Michael

On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
 wrote:
>
> Dear Bioc devel,
>
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr<https://gitlab.gwdg.de/loosolab/software/multicrispr>).
>
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> (Posted earlier on BioC support<https://support.bioconductor.org/p/124442/> 
> and redirected here following Martin's suggestion)
>
> Thankyou :-)
>
> Aditya
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] Import BSgenome class without attaching BiocGenerics (and others)?

2019-09-06 Thread Michael Lawrence via Bioc-devel
The way to keep a "clean namespace" is to selectively import symbols
into your namespace, not to import _nothing_ into your namespace.
Otherwise, your code will fill with namespace qualifications that
distract from what is more important to communicate: the intent of the
code. And no, there's no way to define method signatures using
anything other than simple class names.

It would be interesting to explore alternative ways of specifying
method signatures. One way would be if every package exported a "class
reference" (class name with package attribute, at least)  for each of
its classes. Those could be treated like any other exported object,
and referenced via namespace qualification. It would require major
changes to the methods package but that should probably happen anyway
to support disambiguation when two packages define a class of the same
name. It would be nice to get away from the exportClasses() and
importClasses() stuff. File that under the "rainy year" category.

Michael

On Fri, Sep 6, 2019 at 3:39 AM Bhagwat, Aditya
 wrote:
>
> Dear Bioc devel,
>
> Is it possible to import the BSgenome class without attaching BiocGenerics 
> (to keep a clean namespace during the development of 
> multicrispr).
>
> BSgenome <- methods::getClassDef('BSgenome', package = 'BSgenome')
>
> (Posted earlier on BioC support 
> and redirected here following Martin's suggestion)
>
> Thankyou :-)
>
> Aditya
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



-- 
Michael Lawrence
Scientist, Bioinformatics and Computational Biology
Genentech, A Member of the Roche Group
Office +1 (650) 225-7760
micha...@gene.com

Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel