Re: [Bioc-devel] Remote BigWig file access

[Vincent Carey]

thanks

On Thu, May 23, 2024 at 5:36 PM Chris Wilks (gmail) 
wrote:

> Thanks Vince, understood about the Core's focus right now.
>
>  I think this is something that Leo and I can fix among ourselves for the
> time being.
>
> Looking forward, as you brought up, if we were to refresh recount or
> produce a recount4 (discussed) we'd certainly consider additional coverage
> formats.
>
> I'm aware of tiledb though not duckdb (I'll have to check it out), thanks
> for the pointer.
>
> There's also the D4 format from Aaron Quinlan's lab from a few years ago
> which was explicitly designed to replace bigwigs:
> https://www.nature.com/articles/s43588-021-00085-0
>
> All that said, we're pretty committed to bigwigs at this point given the
> ~750,000 sequence runs we've encoded using them for recount3.
>
> On Wed, May 22, 2024 at 7:17 AM Vincent Carey 
> wrote:
>
>> Really glad to see this discussion moving forward.  I would say that the
>> core is wrangling with some
>> even lower-level technical concerns right now, so I can't jump in just
>> now.  I just want to raise the question
>> of whether bigWig files are a technologically sound format to continue
>> investing in for the use case of
>> targeted remote query resolution on genomic coordinates.  A number of new
>> concepts have come into
>> play since bigWig was designed and implemented.  I'll naively mention
>> duckdb and tiledb, which seem
>> to have very good remote performance.  Maybe these are too generic ...
>> are there other concepts in
>> GA4GH that might be relevant to leverage for recount-like projects in the
>> future?
>>
>>
>>
>> On Wed, May 22, 2024 at 6:58 AM Chris Wilks (gmail) 
>> wrote:
>>
>>> Thanks for sharing Leo, this does interest me, especially since so much
>>> is
>>> built on BigWig access via rtracklayer at least in the recount2
>>> ecosystem.
>>>
>>> As you alluded to, Megadepth currently supports remote access of BigWigs
>>> (and BAMs) over HTTPS on all platforms (Linux, MacOS, and Windows),
>>> getting back just the byte ranges overlapping the set of regions
>>> requested
>>> so it should work for at least recount2/recount3 and anything that uses
>>> HTTP/s.
>>>
>>> I'd be open to exploring updates to the Megadepth C/C++ code side to
>>> support Rle if that makes sense to replace rtracklayer.
>>> But to do that you'd need to be involved in updating all the R packages
>>> if
>>> you're willing (both megadepth and those that currently rely on
>>> rtracklayer
>>> for this functionality).
>>>
>>> Let me know if you want to chat about this over Zoom,
>>> Chris
>>>
>>> On Tue, May 21, 2024 at 2:41 PM Leonardo Collado Torres <
>>> lcollado...@gmail.com> wrote:
>>>
>>> > Hi Bioc-devel,
>>> >
>>> > As some of you are aware, rtracklayer::import() has long provided
>>> > access to import BigWig files. Those files can be shared on servers
>>> > and accessed remotely thanks to all the effort from many of you in
>>> > building and maintaining rtracklayer.
>>> >
>>> > From my side, derfinder::loadCoverage() relies on
>>> > rtracklayer::import.bw(), and recount::expressed_regions() +
>>> > recount::coverage_matrix() use derfinder::loadCoverage().
>>> > recountWorkflow showcases those recount functions on larger datasets.
>>> > brainflowprobes by Amanda Price, Nina Rajpurohit and others also ends
>>> > up relying on rtracklayer::import.bw() through these functions.
>>> >
>>> > At https://github.com/lawremi/rtracklayer/issues/83 I initially
>>> > reported some issues once our recount2/3 data host changed, but
>>> > previously Brian Schilder also reported that one could no longer read
>>> > remote files https://github.com/lawremi/rtracklayer/issues/73.
>>> > https://github.com/lawremi/rtracklayer/issues/63 and/or
>>> > https://github.com/lawremi/rtracklayer/issues/65 might have been
>>> > related.
>>> >
>>> > Yesterday I updated
>>> >
>>> https://github.com/lawremi/rtracklayer/issues/83#issuecomment-2121313270
>>> > with a comment showing some small reproducible code, and that the
>>> > workaround of downloading the data first, then using
>>> > rtracklayer::import() on the local data does work. However, this
>>> > workaround does involve a lot of, hmm, wasteful data transfer.
>>> >

Re: [Bioc-devel] Remote BigWig file access

[Vincent Carey]

Really glad to see this discussion moving forward.  I would say that the
core is wrangling with some
even lower-level technical concerns right now, so I can't jump in just
now.  I just want to raise the question
of whether bigWig files are a technologically sound format to continue
investing in for the use case of
targeted remote query resolution on genomic coordinates.  A number of new
concepts have come into
play since bigWig was designed and implemented.  I'll naively mention
duckdb and tiledb, which seem
to have very good remote performance.  Maybe these are too generic ... are
there other concepts in
GA4GH that might be relevant to leverage for recount-like projects in the
future?



On Wed, May 22, 2024 at 6:58 AM Chris Wilks (gmail) 
wrote:

> Thanks for sharing Leo, this does interest me, especially since so much is
> built on BigWig access via rtracklayer at least in the recount2 ecosystem.
>
> As you alluded to, Megadepth currently supports remote access of BigWigs
> (and BAMs) over HTTPS on all platforms (Linux, MacOS, and Windows),
> getting back just the byte ranges overlapping the set of regions requested
> so it should work for at least recount2/recount3 and anything that uses
> HTTP/s.
>
> I'd be open to exploring updates to the Megadepth C/C++ code side to
> support Rle if that makes sense to replace rtracklayer.
> But to do that you'd need to be involved in updating all the R packages if
> you're willing (both megadepth and those that currently rely on rtracklayer
> for this functionality).
>
> Let me know if you want to chat about this over Zoom,
> Chris
>
> On Tue, May 21, 2024 at 2:41 PM Leonardo Collado Torres <
> lcollado...@gmail.com> wrote:
>
> > Hi Bioc-devel,
> >
> > As some of you are aware, rtracklayer::import() has long provided
> > access to import BigWig files. Those files can be shared on servers
> > and accessed remotely thanks to all the effort from many of you in
> > building and maintaining rtracklayer.
> >
> > From my side, derfinder::loadCoverage() relies on
> > rtracklayer::import.bw(), and recount::expressed_regions() +
> > recount::coverage_matrix() use derfinder::loadCoverage().
> > recountWorkflow showcases those recount functions on larger datasets.
> > brainflowprobes by Amanda Price, Nina Rajpurohit and others also ends
> > up relying on rtracklayer::import.bw() through these functions.
> >
> > At https://github.com/lawremi/rtracklayer/issues/83 I initially
> > reported some issues once our recount2/3 data host changed, but
> > previously Brian Schilder also reported that one could no longer read
> > remote files https://github.com/lawremi/rtracklayer/issues/73.
> > https://github.com/lawremi/rtracklayer/issues/63 and/or
> > https://github.com/lawremi/rtracklayer/issues/65 might have been
> > related.
> >
> > Yesterday I updated
> > https://github.com/lawremi/rtracklayer/issues/83#issuecomment-2121313270
> > with a comment showing some small reproducible code, and that the
> > workaround of downloading the data first, then using
> > rtracklayer::import() on the local data does work. However, this
> > workaround does involve a lot of, hmm, wasteful data transfer.
> >
> > On the recount vignette at some point I access just chrY of a bigWig
> > file that is about 1300 MB. On the recountWorkflow vignette I do
> > something similar for a 7GB bigWig file. Previously accessing just
> > chrY on these files was a small data transfer.
> >
> > On recountWorkflow version 1.29.2
> > https://github.com/LieberInstitute/recountWorkflow, I've included
> > pre-computed results (~2 MB) to avoid downloading tons of data, though
> > the vignette code shows how to actually fully reproduce the results if
> > you don't mind downloading those large files. I also implemented some
> > workarounds on recount, though I haven't yet gone the full route of
> > including pre-computed results. I have yet to try implementing a
> > workaround for brainflowprobes.
> >
> >
> >
> > My understanding is that rtracklayer's root issues are elsewhere and
> > changes in dependencies rtracklayer has likely created these problems.
> > These problems are not always in the control of rtracklayer authors to
> > resolve, and also create an unexpected burden on them.
> >
> > If one considers alternatives to rtracklayer, I see that there's a new
> > package https://github.com/PoisonAlien/trackplot/tree/master that uses
> > bwtool (a system dependency), and older alternative
> > https://github.com/andrelmartins/bigWig that hasn't had updates in 4
> > years, and a CRAN package
> > (https://cran.r-project.org/web/packages/wig/readme/README.html) that
> > recommends using rtracklayer for larger files. I guess that I could
> > also try using megadepth https://research.libd.org/megadepth/, though
> > derfinder::loadCoverage uses rtracklayer::import(as = "RleList") for
> > efficiency
> >
> https://github.com/lcolladotor/derfinder/blob/f9cd986e0c1b9ea6551d0d8d2077d4501216a661/R/loadCoverage.R#L401
> > and lots of 

Re: [Bioc-devel] Question relating to extending a class and inclusion of data

[Vincent Carey]

>
> ...
>
> > Q4: Do you think a separate ExperimentData package satisfying the
> specifications laid out in Background 2 is warranted? This could be
> included in a future version with SummarizedExperiment/MetaboExperiment
> support.
> It depends on the size of the data. For a software package, we limit the
> size of the source tarball to 5G. So if you're going to exceed that
> limit then the datasets need to go in an experiment data package.
>

Not 5G.  Compressed tarball size may not exceed 5MB.  See
https://contributions.bioconductor.org/general.html, sec 3.2.5.


> >
> > Q5: The instructions state that the data needs to be documented (
> https://contributions.bioconductor.org/docs.html#doc-inst-script). Is the
> availability of the original data strictly necessary?  I notice many
> packages don't include documentation on how the data was procured.
>
> The availability of the original data is not strictly necessary but the
> data still needs to be documented i.e. what's its nature, where it's
> coming from, how it was imported/transformed, etc...
>
> Best,
>
> H.
>
> >
> > Thanks,
> > Vilhelm Suksi
> > Turku Data Science Group
> > vks...@utu.fi
> >
> > ___
> > Bioc-devel@r-project.org  mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this email is intended only for the p...{{dropped:15}}

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

Re: [Bioc-devel] AnnotationHub: uniprot seqs ?

[Vincent Carey]

On Tue, May 21, 2024 at 4:18 AM Aditya Bhagwat via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Hey guys,
>
> Do we have Uniprot sequences in AnnotationHub ?
>

That does not seem practical.

Please see
https://bioconductor.org/packages/release/bioc/vignettes/UniProt.ws/inst/doc/UniProt.ws.html

Let us know if that does not meet your need.


> Not being able to find them.
>



>
> Thankyouverymuch : )
>
> Aditya
>
> --
> Aditya Bhagwat
> Translational Proteomics ∙ Philipps-University Marburg
> Biological Pharmacological Center ∙ Room A406
> Tel.: +49 6421 28 27403
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this email is intended only for the p...{{dropped:15}}

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

Re: [Bioc-devel] Important Bioconductor Release Deadlines

[Vincent Carey]

On Fri, Apr 5, 2024 at 12:56 AM Anatoly Sorokin  wrote:
>
> Dear Levi,
>
> minor correction: not requiring but working with. Testing against r-devel
> and requiring it for development are two different things. If the
> development and maintenance of the Bioconductor package would be my only
> responsibility, I wouldn't argue. But because this is a voluntary activity
> additional restrictions such as maintaining unstable software release,
> which is not needed at all, make it less attractive.
>
> In my mind, the requirements mean that the software is not backwards
> compatible any more. In my experience, cases when packages are not working
> with an R older in major release is rare (for example at the moment all my
> code working with R 3.6, due to limitations on some collaborator's
> systems). I haven't checked but it would be really interesting to run R Cmd
> check on 3.19 packages with R 4.0 and find how many of them will fail.
>
> When we were deciding how to release our code Bioconductor was chosen due
> to its stability and user-friendliness in package and dependencies
> installation, which is crucial for the adoption of the analysis approach by
> biologists who are not so familiar with coding. Forcing them to completely
> reinstall the framework is not so convenient.
>
> But anyway it is just my thoughts.
>
> On Fri, Apr 5, 2024 at 12:39 PM Levi Waldron 
> wrote:
>
> > Anatoly, delaying dependency on R 4.4 until October would mean 6 months of
> > Bioconductor release requiring an old release of R for users. Bioconductor
> > developers developing against r-devel means that users get a new
> > Bioconductor release that works immediately on the new R. And I think a
> > main purpose of a 6 month devel and release cycle is to provide a
> > comfortable period for everyone to work out new features and bugs and to
> > resolve downstream consequences that may arise.  Delaying the Bioconductor
> > release by a week or something might actually encourage a habit of
> > last-week bug fixes that should be discouraged . I really can’t see any
> > way around requiring developers to test against r-devel without sacrificing
> > timeliness and reliability for users. There are also Docker and GitHub
> > Actions options that don’t require installing r-devel to test against it.
> >
>
> But the recent release of 3.19 version of GO.db package forced me to the
> last-minute bug fixing of the code, which was perfectly fine, anyway.
>
> >
> > I think many HPC clusters now support Singularity, which is a more
> > reliable and easier way to run packages with a compatible version of R.
> > Installing from GitHub on an old version of R has no guarantees of being
> > tested or working correctly even if it installs without error, and I see as
> > a sacrifice of software reliability for convenience that can be avoided
> > with Singularity or regular R updates.
> >
>
> That's why each package should contain a reliable set of tests. And again,
> regular updates of the R are fine for the self-managed machines and skilful
> users. Don't fix something, which works!
>
> >
> > Henrik, if Bioconductor releases weren’t tied to R releases, how could
> > Bioconductor test them? I guess like CRAN where as long as a package says
> > it depends on R >= 2.0 then you’re free to try installing on 2.0 even
> > though the combination has never been tested? Maybe I worry too much about
> > such testing since CRAN seems OK anyways, as far as we know?
> >
> My point is that too-tight ties make Bioconductor less reliable. When you
> test your code against someone's unstable release you are wasting your
> time, since you have to debug not only your code but the unstable version
> of the platform. I did not sign up as an R beta tester.

Hi Anatoly, sorry to hear about your issue, and I would like to understand more
about the specific technical problem you've encountered.  Maybe we can take
that off line to the developer forum channel in our slack.

On not signing up "as an R beta tester", it may be worth thinking about the
following:  One of the values of participating in an open source community as a
user is the opportunity afforded to "give back" to the many projects
that underlie
any reasonably complex open source tool of interest.  Since the
inception of Bioconductor, I
would say, it is realized that the project is wholly dependent not just upon R
as a language at any given time, but on the evolution of R and CRAN.  Ideas
from Bioconductor such as "vignettes" as package components and testing
resources were brought into R _from Bioconductor_.  R proved adaptable to
the interests of genomic data scientists, who needed vignettes
urgently around the
turn of the century.  Vignettes proved to be very generally valuable, of course,
but their role in packaging started with bioc.  R core members take advantage
of Bioconductor packages to enhance exploration of the surface of
potential language
problems, and "testing against Bioconductor" is a routine part of

Re: [Bioc-devel] Bioconductor 3.19 db0s, OrgDbs, and TxDbs now available

[Vincent Carey]

winging it here tim

> select(Homo.sapiens, keys="ENSG0198727", keytype="ENSEMBL",
columns=c("GENENAME", "GENEID", "CDSCHROM", "SYMBOL"))
'select()' returned 1:1 mapping between keys and columns
  ENSEMBL GENENAME SYMBOL CDSCHROM GENEID
1 ENSG0198727 cytochrome b   CYTB4519
> select(Homo.sapiens, keys= "MTCYBP1", keytype="SYMBOL",
columns=c("GENENAME", "GENEID", "CDSCHROM", "SYMBOL"))
'select()' returned 1:1 mapping between keys and columns
   SYMBOLGENENAME CDSCHROMGENEID
1 MTCYBP1 MT-CYB pseudogene 1  100499418

relevant?

On Thu, Mar 28, 2024 at 9:17 AM Tim Triche, Jr. 
wrote:

> Hi Lori and fellow maintainers,
>
> I had a strange experience yesterday where I pulled down genes and
> transcripts from Homo.sapiens, only to discover that all mitochondrial
> encoded genes (MT-CYB, MT-CO2, etc) were missing.
>
> Is there an historical reason why this is so? Obviously these transcripts
> are physiologically important, but beyond that, they’re also used all the
> time in single cell sequencing to estimate viability.
>
> Best,
>
> --t
>
> > On Mar 28, 2024, at 8:47 AM, Kern, Lori via Bioc-devel <
> bioc-devel@r-project.org> wrote:
> >
> > Hello Bioconductor community,
> >
> > The newest db0, OrgDb, and TxDb annotation packages for the upcoming
> Bioconductor 3.19 release are up and available for download in the devel
> version of Bioconductor.
> >
> > The deadline for submitting contributed annotation packages will be
> Wednesday April 17 th.
> >
> > The new db0 packages are:
> >
> > anopheles.db0_3.19.0.tar.gz
> > arabidopsis.db0_3.19.0.tar.gz
> > bovine.db0_3.19.0.tar.gz
> > canine.db0_3.19.0.tar.gz
> > chicken.db0_3.19.0.tar.gz
> > chimp.db0_3.19.0.tar.gz
> > ecoliK12.db0_3.19.0.tar.gz
> > ecoliSakai.db0_3.19.0.tar.gz
> > fly.db0_3.19.0.tar.gz
> > human.db0_3.19.0.tar.gz
> > malaria.db0_3.19.0.tar.gz
> > mouse.db0_3.19.0.tar.gz
> > pig.db0_3.19.0.tar.gz
> > rat.db0_3.19.0.tar.gz
> > rhesus.db0_3.19.0.tar.gz
> > worm.db0_3.19.0.tar.gz
> > xenopus.db0_3.19.0.tar.gz
> > yeast.db0_3.19.0.tar.gz
> > zebrafish.db0_3.19.0.tar.gz
> >
> > The new OrgDb packages are:
> >
> > GO.db_3.19.0.tar.gz
> > org.Ag.eg.db_3.19.0.tar.gz
> > org.At.tair.db_3.19.0.tar.gz
> > org.Bt.eg.db_3.19.0.tar.gz
> > org.Ce.eg.db_3.19.0.tar.gz
> > org.Cf.eg.db_3.19.0.tar.gz
> > org.Dm.eg.db_3.19.0.tar.gz
> > org.Dr.eg.db_3.19.0.tar.gz
> > org.EcK12.eg.db_3.19.0.tar.gz
> > org.EcSakai.eg.db_3.19.0.tar.gz
> > org.Gg.eg.db_3.19.0.tar.gz
> > org.Hs.eg.db_3.19.0.tar.gz
> > org.Mm.eg.db_3.19.0.tar.gz
> > org.Mmu.eg.db_3.19.0.tar.gz
> > org.Pt.eg.db_3.19.0.tar.gz
> > org.Rn.eg.db_3.19.0.tar.gz
> > org.Sc.eg.db_3.19.0.tar.gz
> > org.Ss.eg.db_3.19.0.tar.gz
> > org.Xl.eg.db_3.19.0.tar.gz
> > Orthology.eg.db_3.19.0.tar.gz
> > PFAM.db_3.19.0.tar.gz
> >
> > The new TxDb packages are:
> >
> > TxDb.Hsapiens.UCSC.hg38.refGene_3.19.0.tar.gz
> > TxDb.Mmusculus.UCSC.mm39.refGene_3.19.0.tar.gz
> >
> > Thank you
> >
> >
> > Lori Shepherd - Kern
> >
> > Bioconductor Core Team
> >
> > Roswell Park Comprehensive Cancer Center
> >
> > Department of Biostatistics & Bioinformatics
> >
> > Elm & Carlton Streets
> >
> > Buffalo, New York 14263
> >
> >
> > This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> >[[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this email is intended only for the p...{{dropped:15}}

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

Re: [Bioc-devel] R package on Github uses Bioconductor depenencies and cant be installed.

[Vincent Carey]

What command was used?  BiocManager::install should resolve the dependencies
whereas straight use of install.packages would not.

On Wed, Feb 28, 2024 at 9:07 AM Ruff, Sergej 
wrote:

> Hello,
>
>
> I have an R package on  Github that uses Bioconductor dependencies:
>
>
> https://github.com/klausjung-hannover/bootGSEA/blob/main/DESCRIPTION
>
>
> One reviewer recently sent me a message that he can´t install the package.
>
> Itried installing the package on a new device and got the following error:
>
>
> Installing package into
> ‘/home/sergejruff/R/x86_64-pc-linux-gnu-library/4.3’
> (as ‘lib’ is unspecified)
> ERROR: dependencies ‘topGO’, ‘ReactomePA’, ‘org.Mm.eg.db’ are not
> available for package ‘bootGSEA’
> * removing ‘/home/sergejruff/R/x86_64-pc-linux-gnu-library/4.3/bootGSEA’
> Warning messages:
> 1: packages ‘org.Mm.eg.db’, ‘ReactomePA’, ‘topGO’ are not available for
> this version of R
>
> Versions of these packages for your version of R might be available
> elsewhere,
> see the ideas at
>
> https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Installing-packages
> 2: In i.p(...) :
>   installation of package
> ‘/tmp/Rtmpnq6hVG/filed7528253e49/bootGSEA_1.0.tar.gz’ had non-zero exit
> status
>
>
> The CRAN dependencies install fine but Bioconductor packages refuse to
> install.
>
>
> Is there a way to solve the problem?
>
>
> I use the following command:
>
>
> library(devtools)
> install_github("klausjung-hannover/bootGSEA")
>
>
> I read that I should use biocView to the description file, but i couldn´t
> find a good source where someone explains why thats right or what biocView
> does?
>
> Could someone help me with my problem and explain if adding Biocview helps
> and more importantly why?
>
>
> Best, Sergej
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Build errors from recent breaking ggplot2 changes

[Vincent Carey]

thanks for the report, we will discuss this today.  it should be possible
to address this soon.

On Tue, Feb 27, 2024 at 6:02 AM Stevie Pederson <
stephen.pederson...@gmail.com> wrote:

> Hi,
>
> I have the package ComplexUpset as a dependency for some packages and the
> recent changes to ggplot2 v3.5.0 have thrown a spanner in the works.
> ComplexUpset calls `theme_minimal()` internally, but it appears that after
> updating to ggplot2 v3.5.0 locally this specific call is still returning
> values as for ggplot2 3.4.x which throws a build error for my packages,
> despite this being a direct call to the ggplot2 function theme_minimal(). I
> suspect that ComplexUpdate's call to theme_minmal() is somehow returning
> values from the version of ggplot2 that was installed at the time of it's
> own install. I uninstalled ComplexUpset locally and reinstalled it and this
> has fixed the error for me. The identical call is now returning values
> which are compatible with ggplot2 v3.5.0
>
> As there are no package updates for ComplexUpset, I can't see this being
> resolved on the BBS any other way than a clean reinstall of ComplexUpset.
> Do complete reinstalls happen regularly, or are they only triggered by
> package updates? If the latter, is there a way of performing a manual
> reinstall of ComplexUpset on the BBS
>
> Sorry if that's a bit confusing. Please see
> https://github.com/krassowski/complex-upset/issues/195 for more details
>
> Thanks Stevie
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Question about cstack usage error

[Vincent Carey]

can you build a reprex for gplots?  we are stretched very thin right now
and i am
sorry to say i don't see this as actionable in our group.

On Tue, Feb 27, 2024 at 2:36 AM Johannes Griss <
johannes.gr...@meduniwien.ac.at> wrote:

> Hi,
>
> We've been encountering a cstack related error on the build systems on
> random occasions
> (
> https://master.bioconductor.org/checkResults/3.18/bioc-LATEST/ReactomeGSA/nebbiolo2-checksrc.html
> ):
>
> Error: C stack usage  7970308 is too close to the limit
>
> I know, that the limit can be adapted using the "ulimit -s 16384"
> command before starting the R session.
>
> Unfortunately, in our case it seems to be caused by a call to the
> gplots::heatmap.2 function.
>
> Thanks a lot!
>
> Kind regards,
> Johannes
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Check time on macOS (MIRit)

[Vincent Carey]

We need a bit of internal discussion before committing to this notion.  I
will get back to the list on this.

On Wed, Feb 7, 2024 at 6:34 AM Jacopo Ronchi 
wrote:

> Dear Vincent, thanks for your answer. So, at least for now, can I ignore
> the warning on macOS for the submission of MIRit?
>
> Il mer 7 feb 2024, 12:26 Vincent Carey  ha
> scritto:
>
>> Thanks Jacopo.  You shouldn't have to struggle.  We are aware of
>> disparities of platform
>> performance and are working to improve the build process.  It will take
>> time.  I believe that
>> achievement of acceptable timings on the linux platform should be the key
>> goal at
>> this time.
>>
>> On Wed, Feb 7, 2024 at 5:18 AM Jacopo Ronchi 
>> wrote:
>>
>>> Dear developers,
>>>
>>> I am struggling to reduce R CMD check times for my package, MIRit, on
>>> macOS. The check on linux takes 4 minutes, while on macOS it needs 9/10
>>> minutes. I have severely reduced the size of examples and tests, which
>>> now
>>> use smaller datasets and cached resources.
>>>
>>> On linux, unit tests require 30 seconds more or less, and examples 40
>>> seconds. On the other hand, macOS tests take 100 seconds, and 75 for the
>>> examples. The issue is that sometimes the check runs in less than 10
>>> minutes, sometimes it needs a little bit more.
>>>
>>> However I am out of ideas on how to further reduce examples and tests...
>>> The vignette is really extensive, but since SPB uses the "--no-vignette"
>>> option this should not influence heavily on this behavior, at least to my
>>> understanding.
>>>
>>> Sorry for bothering you,
>>> Best regards,
>>> Jacopo
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>> The information in this e-mail is intended only for the person to whom it
>> is
>> addressed. If you believe this e-mail was sent to you in error and the
>> e-mail
>> contains patient information, please contact the Partners Compliance HelpLine
>> at
>> http://www.partners.org/complianceline . If the e-mail was sent to you
>> in error
>> but does not contain patient information, please contact the sender and
>> properly
>> dispose of the e-mail.
>
>

-- 
The information in this e-mail is intended only for the person to whom it 
is
addressed. If you believe this e-mail was sent to you in error and the 
e-mail
contains patient information, please contact the Partners Compliance 
HelpLine at
http://www.partners.org/complianceline 
<http://www.partners.org/complianceline> . If the e-mail was sent to you in 
error
but does not contain patient information, please contact the sender 
and properly
dispose of the e-mail.

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Check time on macOS (MIRit)

[Vincent Carey]

Thanks Jacopo.  You shouldn't have to struggle.  We are aware of
disparities of platform
performance and are working to improve the build process.  It will take
time.  I believe that
achievement of acceptable timings on the linux platform should be the key
goal at
this time.

On Wed, Feb 7, 2024 at 5:18 AM Jacopo Ronchi 
wrote:

> Dear developers,
>
> I am struggling to reduce R CMD check times for my package, MIRit, on
> macOS. The check on linux takes 4 minutes, while on macOS it needs 9/10
> minutes. I have severely reduced the size of examples and tests, which now
> use smaller datasets and cached resources.
>
> On linux, unit tests require 30 seconds more or less, and examples 40
> seconds. On the other hand, macOS tests take 100 seconds, and 75 for the
> examples. The issue is that sometimes the check runs in less than 10
> minutes, sometimes it needs a little bit more.
>
> However I am out of ideas on how to further reduce examples and tests...
> The vignette is really extensive, but since SPB uses the "--no-vignette"
> option this should not influence heavily on this behavior, at least to my
> understanding.
>
> Sorry for bothering you,
> Best regards,
> Jacopo
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] hermes Bioconductor

[Vincent Carey]

Oops, I misread this, and can reproduce.  You can clone the current source
out of github in the
container and install it there.

docker run -ti bioconductor/bioconductor_docker:devel bash

   3  git clone https://github.com/bioconductor/S4Arrays
4  R CMD INSTALL S4Arrays

On Fri, Jan 12, 2024 at 9:51 AM Vincent Carey 
wrote:

> I cannot reproduce this with a current pull of the devel container.
> BiocManager installation
> of S4Vectors succeeded.  Please provide the version given in environment
> variable
> BIOCONDUCTOR_DOCKER_VERSION, I used 3.19.13
>
> R Under development (unstable) (2024-01-03 r85769)
> Platform: x86_64-pc-linux-gnu
> Running under: Ubuntu 22.04.3 LTS
>
> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
> LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so;
>  LAPACK version 3.10.0
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> time zone: Etc/UTC
> tzcode source: system (glibc)
>
> attached base packages:
> [1] stats4stats graphics  grDevices utils datasets  methods
> [8] base
>
> other attached packages:
> [1] S4Vectors_0.41.3BiocGenerics_0.49.1
>
> loaded via a namespace (and not attached):
> [1] BiocManager_1.30.22 compiler_4.4.0  tools_4.4.0
>
> On Fri, Jan 12, 2024 at 9:30 AM Sabanes Bove, Daniel via Bioc-devel <
> bioc-devel@r-project.org> wrote:
>
>> Hello,
>>
>> I am trying to reproduce a problem with the hermes package on BioC devel.
>> To this end, I installed docker, and loaded the RStudio session
>> from bioconductor_docker:devel.
>> Now the problem is that I cannot install the dependency S4Arrays because
>> the compilation fails with
>>
>> array_selection.c: In function ‘C_Lindex2Mindex’:
>> array_selection.c:352:17: error: format not a string literal and no
>> format arguments [-Werror=format-security]
>>   352 | error(errmsg_buf());
>>   | ^
>> array_selection.c: In function ‘C_Mindex2Lindex’:
>> array_selection.c:416:17: error: format not a string literal and no
>> format arguments [-Werror=format-security]
>>   416 | error(errmsg_buf());
>>   | ^cc1: some warnings being treated as errors
>>
>>
>> Am I doing something wrong maybe? I expected that S4Arrays should
>> install just fine because
>>
>> https://bioconductor.org/checkResults/devel/bioc-LATEST/S4Arrays/
>>
>> shows that its checks on BioC devel pass, and I assumed that the same
>> Docker image is used?
>>
>>
>> Thanks for your help,
>>
>> best regards
>>
>> Daniel
>>
>>
>> On Thu, Jan 11, 2024 at 8:55 PM Daniel Sabanes Bove <
>> daniel.sabanes_b...@roche.com> wrote:
>>
>> > Thanks a lot,
>> > we will look into this immediately.
>> > Best regards
>> > Daniel
>> >
>> > On Thu, Jan 11, 2024 at 5:37 PM CoreTeam Bioconductor <
>> > bioconductorcoret...@gmail.com> wrote:
>> >
>> >> Hello Package Maintainer,
>> >>
>> >> We would like to bring to your attention that your package is failing
>> in
>> >> devel across all platforms. This is very problematic. Please
>> investigate
>> >> the issues and fix the package to avoid deprecation.
>> >>
>> >> https://bioconductor.org/checkResults/devel/bioc-LATEST/
>> >> <
>> https://bioconductor.org/checkResults/3.17/workflows-LATEST/TCGAWorkflow>
>> >>
>> >> If you have further questions or concerns please reach out on the
>> >> bioc-devel@r-project.org
>> >>
>> >> We appreciate your quick attention to this matter
>> >>
>> >> Cheers,
>> >> On behalf of the Bioconductor Core Team
>> >>
>> >
>> >
>> > --
>> > *Dr. Daniel Sabanés Bové*
>> > Senior Principal Data Scientist
>> >
>> > F. Hoffmann-La Roche Ltd
>> > PD Data Sciences - Data Science Acceleration (DSX)
>> > B. 663
>> > CH-4070 Basel
>> > Switzerland
>> >
>> > Discover our products at go.roche.com/statistical-engineering (internal
>> > page) and go.roche.com/statistical-engineering-presentation (

Re: [Bioc-devel] hermes Bioconductor

[Vincent Carey]

I cannot reproduce this with a current pull of the devel container.
BiocManager installation
of S4Vectors succeeded.  Please provide the version given in environment
variable
BIOCONDUCTOR_DOCKER_VERSION, I used 3.19.13

R Under development (unstable) (2024-01-03 r85769)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 22.04.3 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so;
 LAPACK version 3.10.0

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

time zone: Etc/UTC
tzcode source: system (glibc)

attached base packages:
[1] stats4stats graphics  grDevices utils datasets  methods
[8] base

other attached packages:
[1] S4Vectors_0.41.3BiocGenerics_0.49.1

loaded via a namespace (and not attached):
[1] BiocManager_1.30.22 compiler_4.4.0  tools_4.4.0

On Fri, Jan 12, 2024 at 9:30 AM Sabanes Bove, Daniel via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Hello,
>
> I am trying to reproduce a problem with the hermes package on BioC devel.
> To this end, I installed docker, and loaded the RStudio session
> from bioconductor_docker:devel.
> Now the problem is that I cannot install the dependency S4Arrays because
> the compilation fails with
>
> array_selection.c: In function ‘C_Lindex2Mindex’:
> array_selection.c:352:17: error: format not a string literal and no
> format arguments [-Werror=format-security]
>   352 | error(errmsg_buf());
>   | ^
> array_selection.c: In function ‘C_Mindex2Lindex’:
> array_selection.c:416:17: error: format not a string literal and no
> format arguments [-Werror=format-security]
>   416 | error(errmsg_buf());
>   | ^cc1: some warnings being treated as errors
>
>
> Am I doing something wrong maybe? I expected that S4Arrays should
> install just fine because
>
> https://bioconductor.org/checkResults/devel/bioc-LATEST/S4Arrays/
>
> shows that its checks on BioC devel pass, and I assumed that the same
> Docker image is used?
>
>
> Thanks for your help,
>
> best regards
>
> Daniel
>
>
> On Thu, Jan 11, 2024 at 8:55 PM Daniel Sabanes Bove <
> daniel.sabanes_b...@roche.com> wrote:
>
> > Thanks a lot,
> > we will look into this immediately.
> > Best regards
> > Daniel
> >
> > On Thu, Jan 11, 2024 at 5:37 PM CoreTeam Bioconductor <
> > bioconductorcoret...@gmail.com> wrote:
> >
> >> Hello Package Maintainer,
> >>
> >> We would like to bring to your attention that your package is failing in
> >> devel across all platforms. This is very problematic. Please investigate
> >> the issues and fix the package to avoid deprecation.
> >>
> >> https://bioconductor.org/checkResults/devel/bioc-LATEST/
> >> <
> https://bioconductor.org/checkResults/3.17/workflows-LATEST/TCGAWorkflow>
> >>
> >> If you have further questions or concerns please reach out on the
> >> bioc-devel@r-project.org
> >>
> >> We appreciate your quick attention to this matter
> >>
> >> Cheers,
> >> On behalf of the Bioconductor Core Team
> >>
> >
> >
> > --
> > *Dr. Daniel Sabanés Bové*
> > Senior Principal Data Scientist
> >
> > F. Hoffmann-La Roche Ltd
> > PD Data Sciences - Data Science Acceleration (DSX)
> > B. 663
> > CH-4070 Basel
> > Switzerland
> >
> > Discover our products at go.roche.com/statistical-engineering (internal
> > page) and go.roche.com/statistical-engineering-presentation (public)
> > www.roche.com
> >
> > *Confidentiality Note: *This message is intended only for the use of the
> > named recipient(s) and may contain confidential and/or proprietary
> > information. If you are not the intended recipient, please contact the
> > sender and delete this message. Any unauthorized use of the information
> > contained in this message is prohibited.
> >
> >
> >
> >
>
> --
> *Dr. Daniel Sabanés Bové*
> Senior Principal Data Scientist
>
> F. Hoffmann-La Roche Ltd
> PD Data Sciences - Data Science Acceleration (DSX)
> B. 663
> CH-4070 Basel
> Switzerland
>
> Discover our products at go.roche.com/statistical-engineering (internal
> page) and go.roche.com/statistical-engineering-presentation (public)
> www.roche.com
>
> *Confidentiality Note: *This message is intended only for the use of the
> named recipient(s) and may contain confidential and/or proprietary
> information. If you are not the intended recipient, please contact the
> sender and delete this message. Any unauthorized use of the information
> contained in this message is prohibited.
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information 

Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects

[Vincent Carey]

Thanks Jim, I tend to agree with you.  Christian, I had a look at ArchR but
could not tell where the
system contacts the Bioc annotation elements.  Can you give some hints?
I'd like to be able to
verify compatibility.

On Mon, Dec 11, 2023 at 9:19 AM James W. MacDonald  wrote:

> I don't believe a different OrgDb is required. The OrgDb package is meant
> to provide annotations for genes such as gene symbol or GO term, etc, which
> are orthogonal to the sequence of the genome, so the current version should
> suffice.
>
> -Original Message-
> From: Bioc-devel  On Behalf Of Vincent
> Carey
> Sent: Sunday, December 10, 2023 1:44 PM
> To: Christian Arnold 
> Cc: bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects
>
> Good question.  I believe these will be forthcoming soon.  In the mean
> time you can create your own.  See, for example
>
>
> https://urldefense.com/v3/__https://github.com/vjcitn/BiocT2T/blob/devel/inst/scripts/makeTxDb.R__;!!K-Hz7m0Vt54!ixhBX1kJeZc-9e3gcVgd5OOsvXj8vYfmUZphWadsaXZmdIMiLYcLZEGkJmZhkFTxT-wXY5c_hr0C9adMcpWaIEw$
>
> It's an active area so you can pull a gff file from
> https://urldefense.com/v3/__https://s3-us-west-2.amazonaws.com/human-pangenomics/index.html?prefix=T2T*CHM13*assemblies*annotation*__;Ly8vLw!!K-Hz7m0Vt54!ixhBX1kJeZc-9e3gcVgd5OOsvXj8vYfmUZphWadsaXZmdIMiLYcLZEGkJmZhkFTxT-wXY5c_hr0C9adM7PNUeks$
> and adjust the code noted above for the TxDb.
>
> For the org.db I have to get back to you.
>
> On Sun, Dec 10, 2023 at 12:06 PM Christian Arnold via Bioc-devel <
> bioc-devel@r-project.org> wrote:
>
> > Hello, I am working with the new human T2T-CHM13v2.0  assembly and
> > while a BSgenome package already exists
> > (BSgenome.Hsapiens.NCBI.T2T.CHM13v2.0), I could not find the
> > corresponding TxDb and OrgDb packages. Is there any information when
> > they may also become available so it is easier to work with the new
> > genome for packages like ArchR, which support a custom genome but need
> > these standard annotation packages for their creation?
> >
> >
> > Thanks a lot for any information regarding this!
> >
> > Best, Christian
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/bioc
> > -devel__;!!K-Hz7m0Vt54!ixhBX1kJeZc-9e3gcVgd5OOsvXj8vYfmUZphWadsaXZmdIM
> > iLYcLZEGkJmZhkFTxT-wXY5c_hr0C9adMOtbUwTc$
> >
>
> --
> The information in this e-mail is intended only for th...{{dropped:29}}

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

Re: [Bioc-devel] Missing CHM13v2.0 TxDB and OrgDb objects

[Vincent Carey]

Good question.  I believe these will be forthcoming soon.  In the mean time
you can
create your own.  See, for example

https://github.com/vjcitn/BiocT2T/blob/devel/inst/scripts/makeTxDb.R

It's an active area so you can pull a gff file from
https://s3-us-west-2.amazonaws.com/human-pangenomics/index.html?prefix=T2T/CHM13/assemblies/annotation/
and adjust the code noted above for the TxDb.

For the org.db I have to get back to you.

On Sun, Dec 10, 2023 at 12:06 PM Christian Arnold via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Hello, I am working with the new human T2T-CHM13v2.0  assembly and while
> a BSgenome package already exists
> (BSgenome.Hsapiens.NCBI.T2T.CHM13v2.0), I could not find the
> corresponding TxDb and OrgDb packages. Is there any information when
> they may also become available so it is easier to work with the new
> genome for packages like ArchR, which support a custom genome but need
> these standard annotation packages for their creation?
>
>
> Thanks a lot for any information regarding this!
>
> Best, Christian
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Is my package suitable for Bioconductor?

[Vincent Carey]

agreedthis discussion is best discussed in the open

On Tue, Oct 24, 2023 at 8:57 AM Lluís Revilla 
wrote:

> Hi Tim,
>
> I think there is a mentorship program for cases like this (I am not sure if
> it still accepts mentees):
> https://www.bioconductor.org/developers/new-developer-program/
> I also recommend the book the Bioconductor community wrote to help with
> submissions: https://contributions.bioconductor.org/index.html
>
> Questions are usually posted here, which will not only help you but future
> users/potential contributors with the same doubts/questions.
> So I would recommend that if the previous resources do not help to just
> list your questions here for anyone to chime in.
>
> If you want more feedback, you  may address the question to someone you
> know from the community or using the slack to ask some questions are also
> good options.
>
> Looking forward to seeing the package in Bioconductor.
>
> I hope this helps,
>
> Lluís
>
> On Tue, 24 Oct 2023 at 12:46, Timothy Barry 
> wrote:
>
> > Hello,
> >
> > My collaborators and I are considering submitting our R package for
> > single-cell CRISPR screen data analysis to Bioconductor (package website
> <
> > https://katsevich-lab.github.io/sceptre/> and e-book <
> > https://timothy-barry.github.io/sceptre-book/>). We have several
> > questions about the suitability of our package for Bioconductor and
> changes
> > that we might need to implement to make our package more consistent with
> > Bioconductor package guidelines. Would a member of the Bioconductor team
> be
> > available for a brief (30-60 minute) Zoom call to discuss these issues?
> We
> > would very much appreciate the help.
> >
> > Thank you greatly,
> > Tim Barry
> >
> > Timothy Barry, PhD
> > University of Pennsylvania
> > Department of Statistics and Data Science
> > Postdoctoral researcher
> >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Including large files for the package

[Vincent Carey]

On Thu, Aug 31, 2023 at 7:28 AM Martin Grigorov 
wrote:

> Hello,
>
> Perhaps you could use https://bioconductor.r-universe.dev/BiocFileCache to
> download the big file on demand.
> The benefit is that the file would be stored in ~/.cache/R/yourPackage/
> (for Linux; something similar for Windows/Mac) and reused between sessions.
>

Thanks Martin.  I think that is a possible approach, but the proposals at
http://contributions.bioconductor.org/non-software.html?q=AnnotationHub#annotationexperiment-hub-packages
should also be considered.

Ali, if the documentation regarding *Hub contributions is unclear, please
file an
issue or write back here with the difficulties so that we can improve the
material and
the methods!

Thanks!



>
> Regards,
> Martin
>
> On Tue, Aug 29, 2023 at 5:15 AM Ali Sajid Imami  >
> wrote:
>
> > Hi BioConductor Team,
> >
> > I am a PhD Candidate in the Cognitive Disorders Research lab at the
> > university of Toledo. I am responsible for a number of R packages and our
> > intention is to submit them to bioconductor over the next several
> months. I
> > had just submitted a package drugfindR (
> > https://github.com/CogDisResLab/drugfindR). This was immediately closed
> as
> > my repo had a single file over the 5MB limit.
> >
> > I wanted to ask both if you would reconsider/make an exception or guide
> me
> > in the right direction.
> >
> > This package serves as a way to quickly learch through the LINCS data
> > stored at the ilincs.org portal. The file in question is one of three
> > metadata files that allows the package to function efficiently and
> without
> > having to go through the expensive network requests. It would really be
> > helpful if we could include the file as is. I do not expect more files
> like
> > that to be added to the package at all.
> >
> > Barring that, I have seen the suggestion of using AnnotationHub or
> > ExperimentHub. While I have gone through the documentation, I'm not
> > entirely sure how those services work. Are those services where we can
> > store the data itself or we are expected to host the data elsewhere and
> > create lightweight "pointer" packages. Similarly, I'm not entirely sure
> > which Hub this would go to.
> >
> > Any advice or guidance will be appreciated.
> >
> >
> > Regards,
> > Dr. Ali Sajid Imami
> > LinkedIn 
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Champ Analysis trouble

[Vincent Carey]

Thank you for your note.  This list is for package development.  Please
register
at support.bioconductor.org and post your question there

On Fri, Jul 21, 2023 at 7:14 AM Keasiykan Selvaraju 
wrote:

> Hi. I am having trouble analysing own data in champ. Error keep appearing
> as pd file and green file does not match. There is no error in the file.
> The application run smoothly when the test data is used. Can have some
> assistance to troubleshoot the problem.
> Thank you. Regards
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Python module "tensorflow_probability" not found

[Vincent Carey]

That's great news.  FWIW I am finding that the advice at
https://rstudio.github.io/reticulate/articles/python_dependencies.html
can work to produce properly resolved python dependencies.  Just don't
follow the example literally; the requested
scipy version may not exist.  Version 1.11.1 does. Stay tuned.

On Thu, Jul 6, 2023 at 7:43 AM Charlotte Soneson 
wrote:

> Hi,
>
> in case it's useful: we have a package (orthos) in review (
> https://github.com/Bioconductor/Contributions/issues/3042) which uses
> basilisk to set up a conda environment with tensorflow and keras. It builds
> and runs fine both on GitHub Actions (GitHub repo here:
> https://github.com/fmicompbio/orthos) and on the Single Package Builder.
> We have also tested (locally) that it will use GPUs if available, and that
> the GPU configuration can be controlled from the R session (outside of the
> package), e.g. by setting the CUDA_VISIBLE_DEVICES environment variable.
>
> Charlotte
>
> > On 5 Jul 2023, at 23:12, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> >
> > So I think Kim is interfacing to tensorflow by using the keras package
> from
> > CRAN (partly authored by the Rstudio people). This package leaves it to
> the
> > user to install tensorflow, which is a highly non-trivial installation
> > task. There is some partly helpful instructions for using conda together
> > with reticulate (see the macOS tab on
> > https://tensorflow.rstudio.com/install/local_gpu.html). This is the job
> > that basilisk handles for you. In essence, basilisk allows the developer
> to
> > specify an R-package-specific conda. Tensorflow can be run on a CPUor a
> > GPU. Getting it to run on a user-GPU is extra complicated and I am not
> sure
> > basilisk can handle this.
> >
> > Going forward, we (Bioc) want to decide if we want to support keras on
> our
> > build system. This will require some work, because it is definitely not
> > trivial to get to work (but much more possible if we limit ourselves to
> > running on CPU). If we decide to support keras, we should try to figure
> out
> > how to wrap keras into a basilisk container; perhaps something like
> > creating a keras-basilisk R package, because IF we decide to support
> keras,
> > this is going to be a major headache (to add to the frustration,
> tensorflow
> > often rearranges everything so I future issues keeping it operational).
> >
> > For Kim: I think you should consider if there are any alternatives to
> > keras. Even if we get it to work on our build system, users will have
> major
> > headache getting this to work (I think). If there are no alternatives to
> > keras, you should perhaps think about doing the keras-basilisk option I
> > outline above (assuming that is feasible; I don't know how keras
> interfaces
> > with tensorflow. You might also have major headaches in your future: I
> have
> > found quite big differences in convergence and optimizers over time in TF
> > and you're basically saying it should work with every version of
> tensorflow
> >> = 2.2. That's a  strong promise considering also the difference
> > between GPU and CPU.
> >
> > In the meantime, in case the core build team wants some input, I have
> some
> > experience with tensorflow, although so far my experience is mostly
> > frustration.
> >
> > Best,
> > Kasper
> >
> >
> > On Wed, Jul 5, 2023 at 3:12 PM Vincent Carey  >
> > wrote:
> >
> >> I'll try to get clearer on the basilisk situation; I forked your repo
> >> and will plunge in soon.
> >> It may take a while.  In the mean time I hope the BBS python stack can
> >> be looked at
> >> to see what the issue might be.  @Jennifer Wokaty is it possible with
> >> the recent R upgrades that
> >> tensorflow and tensorflow-probability might need to be
> installed/updated?
> >>
> >> On Wed, Jul 5, 2023 at 3:01 PM Kim Philipp Jablonski
> >>  wrote:
> >>>
> >>> Thanks a lot for your response!
> >>>
> >>> The Config/reticulate approach in DESCRIPTION looks very neat. I hope
> we
> >> can use it at some point.
> >>>
> >>> Could the issue you are facing with the conda install be, that the
> >> package is called "tensorflow-probability" instead of
> >> "tensorflow_probability" (
> >> https://anaconda.org/conda-forge/tensorflow-probability)?
> >>>
> >>> I have followed the basilisk advice and incorporated it into my package
> >> here: https://github.com/cbg-ethz

Re: [Bioc-devel] Python module "tensorflow_probability" not found

[Vincent Carey]

I'll try to get clearer on the basilisk situation; I forked your repo
and will plunge in soon.
It may take a while.  In the mean time I hope the BBS python stack can
be looked at
to see what the issue might be.  @Jennifer Wokaty is it possible with
the recent R upgrades that
tensorflow and tensorflow-probability might need to be installed/updated?

On Wed, Jul 5, 2023 at 3:01 PM Kim Philipp Jablonski
 wrote:
>
> Thanks a lot for your response!
>
> The Config/reticulate approach in DESCRIPTION looks very neat. I hope we can 
> use it at some point.
>
> Could the issue you are facing with the conda install be, that the package is 
> called "tensorflow-probability" instead of "tensorflow_probability" 
> (https://anaconda.org/conda-forge/tensorflow-probability)?
>
> I have followed the basilisk advice and incorporated it into my package here: 
> https://github.com/cbg-ethz/pareg/tree/feature-basilisk.
> The basilisk docs say "Any R functions that use Python code should do so via 
> basiliskRun()".
> This does not seem possible in my case as I am using tensorflow(probability) 
> wrappers instead of calling them directly.
> Building the vignettes with Github Actions fails because tensorflow could not 
> be found: 
> https://github.com/cbg-ethz/pareg/actions/runs/5466980003/jobs/9952690137#step:15:39
>  (I might have to activate basilisk somehow, but using basiliskStart seems to 
> only make sense with basiliskRun). I could also not find any advice on this 
> elsewhere.
> Do you have a suggestion how to best handle this (or should it *just* work)?
>
>
> On Tue, Jul 4, 2023 at 1:04 PM Vincent Carey  
> wrote:
>>
>> Sorry to hear about this.  Our informal outlook on python
>> interoperation in Bioconductor packages is that
>> the basilisk discipline should be used.  This allows you to pin
>> specific versions of all python dependencies
>> and use python for your R functions from an insulated conda environment.
>>
>> There is also information about specifying python dependencies in the
>> DESCRIPTION file at
>> https://rstudio.github.io/reticulate/articles/python_dependencies.html
>>  I do not know if our build
>> system or R CMD install take effective advantage of that approach at this 
>> time.
>>
>> I was surprised to see that my attempt to use reticulate::py_install()
>> to install tensorflow_probabiliity
>> on my laptop failed:
>>
>> '/home/stvjc/.local/share/r-miniconda/bin/conda' 'install' '--yes'
>> '--prefix' '/home/stvjc/.local/share/r-miniconda/envs/r-reticulate'
>> '-c' 'conda-forge' 'tensorflow_probability'
>> Retrieving notices: ...working... done
>> Collecting package metadata (current_repodata.json): done
>> Solving environment: unsuccessful initial attempt using frozen solve.
>> Retrying with flexible solve.
>> Collecting package metadata (repodata.json): done
>> Solving environment: unsuccessful initial attempt using frozen solve.
>> Retrying with flexible solve.
>>
>> PackagesNotFoundError: The following packages are not available from
>> current channels:
>>
>>   - tensorflow_probability
>>
>> Current channels:
>>
>>   - https://conda.anaconda.org/conda-forge/linux-64
>>   - https://conda.anaconda.org/conda-forge/noarch
>>   - https://repo.anaconda.com/pkgs/main/linux-64
>>   - https://repo.anaconda.com/pkgs/main/noarch
>>   - https://repo.anaconda.com/pkgs/r/linux-64
>>   - https://repo.anaconda.com/pkgs/r/noarch
>>
>> To search for alternate channels that may provide the conda package you're
>> looking for, navigate to
>>
>> https://anaconda.org
>>
>> and use the search bar at the top of the page.
>>
>>
>> Error: one or more Python packages failed to install [error code 1]
>>
>> Enter a frame number, or 0 to exit
>>
>> 1: py_install("tensorflow_probability")
>>
>> So the "current channels" used by reticulate in my pretty stock
>> installation of R/reticulate seem flawed
>> for this purpose.  I had hoped to write a bit of code that would check
>> for the desired module and install
>> it if missing, that you could include in your package.
>>
>> get_pippath = function() {
>>pypath = reticulate::conda_list() |> (\(x)x[x$name=="r-reticulate",])()
>>gsub("python$", "pip", pypath$python)
>> }
>>
>> check_tfp = function() {
>>pippath = get_pippath()
>>peek = system(paste0(pippath, " list | grep tensor"), intern=TRUE)
>>peek = gsub(" +", " ", peek)
>>t

Re: [Bioc-devel] Python module "tensorflow_probability" not found

[Vincent Carey]

Sorry to hear about this.  Our informal outlook on python
interoperation in Bioconductor packages is that
the basilisk discipline should be used.  This allows you to pin
specific versions of all python dependencies
and use python for your R functions from an insulated conda environment.

There is also information about specifying python dependencies in the
DESCRIPTION file at
https://rstudio.github.io/reticulate/articles/python_dependencies.html
 I do not know if our build
system or R CMD install take effective advantage of that approach at this time.

I was surprised to see that my attempt to use reticulate::py_install()
to install tensorflow_probabiliity
on my laptop failed:

'/home/stvjc/.local/share/r-miniconda/bin/conda' 'install' '--yes'
'--prefix' '/home/stvjc/.local/share/r-miniconda/envs/r-reticulate'
'-c' 'conda-forge' 'tensorflow_probability'
Retrieving notices: ...working... done
Collecting package metadata (current_repodata.json): done
Solving environment: unsuccessful initial attempt using frozen solve.
Retrying with flexible solve.
Collecting package metadata (repodata.json): done
Solving environment: unsuccessful initial attempt using frozen solve.
Retrying with flexible solve.

PackagesNotFoundError: The following packages are not available from
current channels:

  - tensorflow_probability

Current channels:

  - https://conda.anaconda.org/conda-forge/linux-64
  - https://conda.anaconda.org/conda-forge/noarch
  - https://repo.anaconda.com/pkgs/main/linux-64
  - https://repo.anaconda.com/pkgs/main/noarch
  - https://repo.anaconda.com/pkgs/r/linux-64
  - https://repo.anaconda.com/pkgs/r/noarch

To search for alternate channels that may provide the conda package you're
looking for, navigate to

https://anaconda.org

and use the search bar at the top of the page.


Error: one or more Python packages failed to install [error code 1]

Enter a frame number, or 0 to exit

1: py_install("tensorflow_probability")

So the "current channels" used by reticulate in my pretty stock
installation of R/reticulate seem flawed
for this purpose.  I had hoped to write a bit of code that would check
for the desired module and install
it if missing, that you could include in your package.

get_pippath = function() {
   pypath = reticulate::conda_list() |> (\(x)x[x$name=="r-reticulate",])()
   gsub("python$", "pip", pypath$python)
}

check_tfp = function() {
   pippath = get_pippath()
   peek = system(paste0(pippath, " list | grep tensor"), intern=TRUE)
   peek = gsub(" +", " ", peek)
   tfdf = do.call(rbind, lapply(strsplit(peek, " "), function(x)
data.frame(pkg=x[1], version=x[2])))
   "tensorflow_probability" %in% tfdf$pkg
}

install_tfp = function() {
   pippath = get_pippath()
   chk = system(paste(pippath, "install tensorflow_probability"), intern=TRUE)
   chk2 = check_tfp()
   list(sysout=chk, tfp_installed=chk2)
}

The first two functions seem to do what I want, the latter does not.

Suggestion -- read the basilisk vignettes, use it if at all possible.
Certainly we can take
care of this in our build system when the holiday ends, but it would
be great to have the software
arrange the solution when necessary, and I don't see a way to
accomplish this at the moment.



On Tue, Jul 4, 2023 at 5:32 AM Kim Philipp Jablonski
 wrote:
>
> Hello,
>
> The latest builds of my package 'pareg' started failing on BioC 3.17 for
> Linux and macOS but not Windows:
> https://master.bioconductor.org/checkResults/3.17/bioc-LATEST/pareg/nebbiolo1-buildsrc.html
> .
> In both cases, the error messages is "Python module tensorflow_probability
> was not found". This wasn't an issue in earlier releases.
>
> Do you know what the reason for this is and how I can fix it?
> Thanks a lot for your help!
>
> Best regards,
> Kim
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
The information in this e-mail is intended only for the ...{{dropped:16}}

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

Re: [Bioc-devel] package failing

[Vincent Carey]

Please provide more details in the future.  What is the name of the
package, which branch
of Bioconductor?  The packages I can see seem to be in a warning state.

* checking Rd \usage sections ... WARNING
Documented arguments not in \usage in documentation object
'show,SampleSet-method':
  ‘...’

Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.
See chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking R/sysdata.rda ... OK
* checking files in ‘vignettes’ ... WARNING
Files in the 'vignettes' directory but no files in 'inst/doc':
  ‘MyEndnoteLibrary.bib’ ‘funtooNorm.Rmd’ ‘funtooNorm.pdf’
  ‘validationcurvesPCRlow.jpg’
Files named as vignettes but with no recognized vignette engine:
   ‘vignettes/funtooNorm.Rmd’
(Is a VignetteBuilder field missing?)

The DESCRIPTION File needs to be improved for the latter.


On Wed, Jun 28, 2023 at 7:32 PM Kathleen Oros Klein <
kathleen.kl...@mail.mcgill.ca> wrote:

> My package is failing, install and build are OK but under check I have
> timeout.
> Anyone can help me how to fix this?
> kathleen
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Urgent minor deployment of a release?

[Vincent Carey]

On Tue, Jun 20, 2023 at 1:34 AM Henrik Bengtsson 
wrote:

> On Mon, Jun 19, 2023 at 5:46 PM Vincent Carey
>  wrote:
> >
> > Hi Adam, thanks for your note.
> >
> > Changes to release branch sources must be limited to bug fixes or doc
> > improvement.  Any new features
> > must be introduced only in the devel branch.
>
> I know about this, but I wanted to find what the document exactly says
> about this. I'm sure it's documented somewhere, but I just spend 10-15
>

I agree with your conclusion here.  I don't think this is documented in the
contributions.bioconductor.org.  I am sorry about the 15 minutes, I should
have commented when I responded that we need to improve the doc
on this.


> min on the website trying, but I couldn't find it.  What I was looking
> specifically for was "new features".  For instance, would one be
> allowed to introduce a 100% backward compatible new features to the
> Bioc release branch? For instance, assume you currently have
>
> h <- function(x, ...) {
>   sum(x)
> }
>
> in the release branch, would it be okay to add:
>
> h <- function(x, na.rm = FALSE, ...) {
>   sum(x, na.rm = na.rm)
> }
>
> ?  This is how base-R itself does it in their patch releases, e.g. R
> 4.3.0 -> R 4.3.1.
>

The intent is that the APIs for packages in the release branch be "stable".
Let's discuss how to formalize and document this intent.


>
> /Henrik
>
> > Any features to be removed
> > must be indicated as
> > deprecated for one release and then labeled as defunct.  See
> >
> > http://contributions.bioconductor.org/deprecation.html
> >
> > for guidan
> > Changes to release branch sources must be limited to bug fixes or doc
> > improvement.
> > ce on feature removal.
> >
> >
> > On Mon, Jun 19, 2023 at 10:11 AM Park, Adam Keebum 
> > wrote:
> >
> > > Hi all,
> > >
> > > I wonder if there is any room for deploying a modification to a
> released
> > > library(retrofit, 3.17), which was released last month.
> > >
> > > We are in a progress of a paper review, so the release schedule (twice
> > > each year) does not perfectly fit our need.
> > >
> > > Or do you think we should have used "devel" for such purposes?
> > >
> > > Sincerely,
> > > Adam.
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > >
> >
> > --
> > The information in this e-mail is intended only for the ...{{dropped:18}}
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Urgent minor deployment of a release?

[Vincent Carey]

Hi Adam, thanks for your note.

Changes to release branch sources must be limited to bug fixes or doc
improvement.  Any new features
must be introduced only in the devel branch.  Any features to be removed
must be indicated as
deprecated for one release and then labeled as defunct.  See

http://contributions.bioconductor.org/deprecation.html

for guidance on feature removal.


On Mon, Jun 19, 2023 at 10:11 AM Park, Adam Keebum 
wrote:

> Hi all,
>
> I wonder if there is any room for deploying a modification to a released
> library(retrofit, 3.17), which was released last month.
>
> We are in a progress of a paper review, so the release schedule (twice
> each year) does not perfectly fit our need.
>
> Or do you think we should have used "devel" for such purposes?
>
> Sincerely,
> Adam.
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] there is no package called ‘BiocStyle’

[Vincent Carey]

In SC3 you have Suggests: on two different lines in DESCRIPTION.  The
second one supersedes the first, I suppose.

On Thu, May 25, 2023 at 6:06 AM Vladimir Kiselev <
vladimir.yu.kise...@gmail.com> wrote:

> Hello,
>
> Recently two of my packages (SC3 and scmap) started failing checks due to:
> "there is no package called ‘BiocStyle'' error. I've added "Suggests:
> BiocStyle" into my DESCRIPTION file both on the devel and RELEASE_3_17 as
> was advised in the corresponding email and bumped the versions. However, my
> packaging is still failing the Linux check:
>
> http://bioconductor.org/checkResults/release/bioc-LATEST/SC3/nebbiolo1-checksrc.html
>
>
> Here is how the version and suggests fields look like in the DESCRIPTION
> file of the RELEASE_3_17 branch:
>
> Version: 1.28.2
> Suggests: BiocStyle
>
> Any suggestions/help would be really appreciated.
>
> Kind regards,
> Vlad
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] BiocManager::install

[Vincent Carey]

Thanks for these observations Wolfgang, I am glad I read to the end,
because as you say,

https://solutions.posit.co/envs-pkgs/bioconductor/

has lots of interesting information.  As I personally have no
experience with renv or Connect
much of the motivating detail is opaque to me.

I would question the proposition

"Given the structural differences between BioConductor and CRAN
repositories, it is not straightforward to work with both types. "

with at least 10 years of history of effective usage of both together
by many hundreds of users.  "Straightforward" is
subjective.  The existence of some shortcomings, like the specific
ones you mention, is acknowledged, and setting
up priorities to ameliorate them would be worthwhile.  Part of the
prioritization would need to be based on user
data and user experiences.  In the case of this posit.co article, what
is known about the significance of Connect
for genomic data science?  I have not had great difficulty publishing
apps to shinyapps.io that use Bioconductor
and CRAN, but perhaps it can be made easier if that is a key concern.

The problem of smoothly supporting multiple versions of R/Bioc
simultaneously is also acknowledged.  At this
time we do not have sufficient resources to make a big charge in the
direction of increasing support for this
"use case".  Users and sysadmins with sufficient expertise can
definitely accomplish much in this area, see
https://bioconductor.org/about/release-announcements/ for the map of
resources supporting this going back to
2005.  If there is a way to simplify this by using recently developed
package management strategies is would
be good to know and document.

This is a good place to continue the discussion from a developer's
perspective, but how can we get more
input from non-developer users?  And from posit.co?

"Publishing Shiny Apps that make use of BioConductor packages to
Connect is not possible for this setup.
BiocManager::install() temporarily adds the BioConductor repository
for the duration of the install process.
During the publishing process rsconnect no longer has any knowledge
about BioConductor." -- is this something
that can be remedied in BiocManager?  Are we able to test Connect for
this use case?


On Sat, May 6, 2023 at 4:40 AM Wolfgang Huber  wrote:
>
> Hi,
>
> I am wondering whether:
> 1. it could be easier to install Bioconductor packages (devel or release) on 
> R-devel (or other non-standard R versions) using BiocManager::install (I may 
> be stirring a hornet’s nest with that:)
> 2. whether its documentation needs to be updated and/or its implementation 
> could be deconvoluted (hopefully that’s uncontroversial).
>
> Re the first point, I appreciate that we’re trying to help non-expert users 
> with simple use cases, and that we had/have a lot of trouble with users 
> working with out-of-sync versions. OTOH, the current solution (rigid, 
> confusing documentation, seemingly buggy implementation) seems to be standing 
> in the way for developers, a dichotomy that we do not really want.
>
> Of course, a workaround is
> ```{r}
> > install.packages("ggtree", repos = c(“@CRAN@", 
> > "https://bioconductor.org/packages/3.18/bioc;)
> ```
> and maybe this is just the answer. So far, my workflows have been based on 
> BiocManager::install, but I get (and cannot seem to get rid of):
>
> ```{r}
> > options(BIOCONDUCTOR_ONLINE_VERSION_DIAGNOSIS = FALSE)
> > BiocManager::install("ggtree", version = "devel")
> Error: Bioconductor does not yet build and check packages for R version 4.4; 
> see
>   https://bioconductor.org/install
>
> > sessionInfo()
> R Under development (unstable) (2023-05-05 r84398)
> Platform: aarch64-apple-darwin20 (64-bit)
> Running under: macOS Ventura 13.3.1
>
> Matrix products: default
> BLAS:   
> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
> LAPACK: 
> /Users/whuber/R.framework/Versions/4.4/Resources/lib/libRlapack.dylib;  
> LAPACK version 3.11.0
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> time zone: Europe/Berlin
> tzcode source: internal
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] BiocManager_1.30.20 fortunes_1.5-4
>
> loaded via a namespace (and not attached):
> [1] compiler_4.4.0  tools_4.4.0 rstudioapi_0.14
> ```
>
> I noted some discussion on this here: 
> https://github.com/Bioconductor/BiocManager/issues/13 but this was 5 years 
> ago.
> It appears that the documentation of BiocManager::install mismatches its 
> implementation, and overall the process for something that's conceptually 
> quite simple seems to have become convoluted.
>
> One of the most helpful documentation resources on this topic btw is 
> https://solutions.posit.co/envs-pkgs/bioconductor/ which cheerfully concludes 
> "Working with BioConductor packages for code development is possible."
>
> Thanks and best 

Re: [Bioc-devel] Participating in the development of Bioconductor

[Vincent Carey]

Hi Franck, thanks for writing.  I think it would be great to hear from
users about performance
concerns.  We would like to do more profiling and instrumentation of key
worksteps to help
increase throughput and ensure available compute resources are used.  In
the cuda/gpu
space we don't have anything touching

https://github.com/NVIDIA-Genomics-Research/rapids-single-cell-examples

as far as I know and it would be interesting if you would have a look at
this and see whether
the is a clear path to some development integrating these approaches.

You might want to join our community slack for more interaction.
slack.bioconductor.org

Best regards
Vince Carey

On Wed, May 3, 2023 at 12:12 PM Franck RICHARD 
wrote:

> Hello community!
>
> I am the author of several software programs including this astronomy
> program: https://winstars.net/en I recently had the opportunity to
> participate in the activities of a neuroscience laboratory in Madrid. I
> learned how to use Bioconductor and I would like to participate in the
> development of new features (if possible). The researchers in the lab
> complain about the slowness of these tools when used on simple PCs. So I
> wonder if it would not be interesting to integrate Cuda in some indexing
> packages, I think of Bowtie2 or Salmon for example... (there is a
> version of bowtie2 that works with cuda, but it seems old). But the task
> would be very complex I guess. There are simpler things to do, like
> creating a wrapper for Salmon or something like that. What do you think
> would be useful to do at this moment for Bioconductor users?
>
> With my thanks,
>
> Franck
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] TCGAbiolinks fails

[Vincent Carey]

The problem is that it is in an error state

--- re-building ‘subtypes.Rmd’ using rmarkdown
Quitting from lines 114-121 (subtypes.Rmd)
Error: processing vignette 'subtypes.Rmd' failed with diagnostics:
object 'lgg.gbm.subtype' not found
--- failed re-building ‘subtypes.Rmd’

so the standard installation approach isn't working now.


https://github.com/BioinformaticsFMRP/TCGAbiolinks -- file an issue


In an emergency you might succeed with

BiocManager::install("BioinformaticsFMRP/TCGAbiolinks")




On Fri, Apr 28, 2023 at 9:07 AM Elizabeth Cattaneo <
elizabethcatta...@gmail.com> wrote:

> Hello!
> I was trying to use TCGAbiolinks as usual in a R-Colab notebook but I got
> this error:
>
> Bioconductor version 3.17 (BiocManager 1.30.20), R 4.3.0 (2023-04-21)
> Installing package(s) 'TCGAbiolinks' Warning message: *“package
> ‘TCGAbiolinks’ is not available for *
> *Bioconductor version '3.17'*
>
> What should I do to fix it?
>
> Thanks!
>
> Elizabeth
>
> --
> Bioq. Elizabeth Cattaneo
> Dra Fac. Cs. Exactas, UNLP
> INIBIOLP, Fac. Cs.Médicas, UNLP
> calle 60 y 120 S/N, 1900 La Plata
> Argentina
> Tel. +54 221 4824894
> www.inibiolp.org.ar
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Installation of XCMS on R

[Vincent Carey]

please pose your question with details of error messages to
support.bioconductor.org  no telephone contacts should be provided or used

On Thu, Feb 23, 2023 at 6:04 PM insaf ben  wrote:

> Hello,
>
> I have a problem installing the xcms library on my R studio 4.2. Could you
> help me do this plz ?
> my phone number is +33(0)769345085
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] DESeq2 package

[Vincent Carey]

You can read the description file (e.g., help(package="DESeq2")), but the
best way is to pose a question at support.bioconductor.org as
many people with good experience are reading that at all hours

On Tue, Jan 24, 2023 at 7:13 AM Claudio A Bravo  wrote:

> Hi-
>
> Could you please direct me to the person that can answer questions about
> this package?
>
> Best,
>
> -
> Claudio Bravo, MD, FACC, FESC
> Assistant Professor
> Advanced Heart Failure & Transplant Cardiology
> University of Washington
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Proposing patch to Bioconductor package

[Vincent Carey]

Thanks for checking in Duncan.  I don't believe we have a guideline on this.

We have code.bioconductor.org that facilitates search of the entire
codebase.  If
you provide a list of the functions that should not be used, I will see
about making
a focused message to the developers who need to change their code.

It really is up to the contributing developers to be aware of effects of
upstream changes,
but this is an opportunity for us to be a little more proactive about
notifying contributors
of events that could break packages in the release branch.

We can communicate about the details off line and then get back to the list
about the
basic process.  Or, if you want to handle the communications, go ahead --
BiocPkgTools
has some utilities that may be relevant.

On Sat, Jan 14, 2023 at 5:33 AM Duncan Murdoch 
wrote:

> To BioC Devel:
>
> I'm updating the rgl package.  I think about 30 Bioconductor packages
> depend on it, and some of them are using obsolete functions which are
> going to be deprecated in the next release.  I'd like to inform those
> maintainers so their packages still work.
>
> Are there specific BioC guidelines for how I should inform them, or is
> it just like CRAN, do what the DESCRIPTION file says?
>
> Duncan Murdoch
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Large vignettes

[Vincent Carey]

On Thu, Jan 12, 2023 at 5:29 AM Lluís Revilla 
wrote:

> Hi all,
>
> Perhaps instead of long vignettes, it would be better to use a book hosted
> and in sync with the packages at Bioconductor.
> There are already a few: https://www.bioconductor.org/books/release/
> But I was not able to find how to submit such bookdowns to Bioconductor (I
> briefly searched the website and the dev book at
> https://contributions.bioconductor.org/docs.html?q=book).
> I think the limits are less restrictive and there is no minimum size of
> chapters or documentation, but I am not sure.
>

I like this idea -- but I want to say a few things, really just personal
observations, nothing "official", and there
may need to be corrections to some of these remarks.

First, the concept that the bioconductor build system could handle
monograph-size artifacts was improvised as the
OSCA book came into being.  There is interesting and intricate
infrastructure there supporting cross-referenced
computations to reduce redundant computation, but I don't think that has
become an "authoring standard" and
it requires some specialized knowledge to use.  Upshot -- we have some
attractive examples of monograph/book
artifacts but we don't really have a standard approach to guide authors to
efficiently deployable products, and the
tooling to build and check the monographs regularly is somewhat limited.

Second, a book becomes a sub-ecosystem, necessarily of both CRAN and
Bioconductor.  We want the
book to remain valid and computable at all times, certainly in the release
branch, but as packages on
which the book depends change and perhaps disappear (happens primarily with
CRAN) the book production
can fail.  Authors have to be vigilant and responsive to events of this
sort.

Third, the narrative of a book is synchronized with the computations when
it is authored, but underlying
software evolution can make prose statements in the book become false over
time.  We saw this with text describing
cluster identities in single-cell analysis ... when a certain projection
function in an upstream package was
modified, cluster labeling silently changed and the text became false.  We
want some kind of flagging
procedure that will alert us to changes of this sort.

There are technical responses to all of these observations but implementing
well-engineered solutions will
require more resources than we currently have.  The workshop authoring
method used in
https://github.com/seandavi/BuildABiocWorkshop is surely relevant; Alex
Mahmoud has a work
in progress called BiocDeployables that is also relevant.  Ultimately we
want to improve communication
of good analytic methods to the scientific community, and monograph-scale
resources are definitely
useful, but smaller-scale resources that don't require the technology of
package production can also
be valuable, and BiocDeployables goes in that direction.  Maintenance and
the avoidance of bit/doc rot
are first-class concerns and really require author commitment.


>
> Some authors already have books outside bioconductor to have extensive
> examples of their packages.
> They will also benefit from having them with the Bioconductor framework
> and in sync with the packages released to the users.
>
> Best,
>
> Lluís
>
>
> On Wed, 4 Jan 2023 at 21:39, Vincent Carey 
> wrote:
>
>> I am glad you brought this up here, and I welcome further discussion on
>> this mailing list.  It is important to understand the constraints on
>> development
>> that arise from Bioconductor's package guidelines.
>>
>> I don't think we want to change the limits on package payload size without
>> understanding the consequences for users and our build system.  The split
>> approach mentioned by Lambda seems sensible to me, and I hope it is
>> not too burdensome.  Additional commentary and details from the community
>> are welcome.
>>
>> On Wed, Jan 4, 2023 at 3:21 PM Lambda Moses  wrote:
>>
>> > Hi Adam,
>> >
>> > I also got this problem, and I would like some input from Bioc Core
>> > Team. I worked around it by writing a minimal vignette in the main
>> > branch. Then I made a documentation branch, where I have the same code
>> > as in main branch, but with more elaborate vignettes used to build a
>> > pkgdown website. I made a rule for myself that I can only merge from the
>> > main or devel branch to the documentation branch but not the other way
>> > round. I would switch branch when I find a bug or want a new feature
>> > while writing the vignettes. You can see the main branch here:
>> > https://github.com/pachterlab/voyager/tree/main The documentation
>> branch
>> > here: https://github.com/pachterlab/voyager/tree/documentation
>> >
>> > I kind o

Re: [Bioc-devel] Support for Linux ARM64

[Vincent Carey]

On Thu, Jan 5, 2023 at 7:08 PM Vincent Carey 
wrote:

>
>
> On Thu, Jan 5, 2023 at 1:44 PM Hervé Pagès 
> wrote:
>
>> Hi Martin,
>>
>> Linux runs on many architectures, ARM64 is just one of them.
>>
>> Our daily builds have traditionally focused on 3 platforms: Intel-based
>> Linux (Ubuntu 22.04), Windows, and Intel-based Mac. Note that we
>> recently added ARM64-based Mac to our daily builds.
>>
>> One big difference between Linux and the other platforms is that we only
>> produce binary packages for the latter. More precisely:
>>
>> - on the Linux builders: the daily builds only run 'R CMD INSTALL', 'R
>> CMD build', and 'R CMD check', on each Bioconductor package,
>>
>> - on the Windows and Mac builders: the daily builds run all the above
>> plus an additional step that we call the BUILD BIN step that produces a
>> binary for each Bioconductor package.
>>
>> This means that on Linux, as well as on any other Unix-like OS that is
>> not macOS (e.g. FreeBSD, OpenBSD, Solaris, HP-UX, etc...), users will
>> install all their packages (Bioconductor and CRAN) **from source**. This
>> should work as long as they are on a platform where R is supported and
>> have the required compilers (C, C++, and Fortran).
>>
>> Note that if officially supporting a given platform means running the
>> daily builds on that particular platform, then there's no way for us to
>> do that because platform == OS + architecture, and the list of
>> combinations of Unix-like OS's (Linux, FreeBSD, Solaris, etc...) +
>> architectures (Intel, ARM64, Sparc, powerpc) is endless. Even if we
>> narrow this list to Intel-based Linux, there are hundreds of Linux
>> distributions around that use different kernel, compilers, package
>> managers, etc...
>>
>> All this to say that, as far as the daily builds are concerned, we had
>> to make choices, and those choices are based on the most commonly used
>> platforms. Since all Bioconductor packages are tested daily on
>> Intel-based Linux (Ubuntu 22.04), Windows, Intel-based Mac, and
>> ARM64-based Mac, we have some reasonable confidence that they will work
>> properly on these 4 platforms (still not a 100% guarantee of course,
>> there's nothing like that).
>>
>> My understanding is that ARM64-based Linux is still a marginally used
>> platform so probably not worth for us to allocate resources on adding it
>> to our daily builds at the moment. If it ever becomes more mainstream in
>> the future, then we will certainly reconsider. That does not mean that
>> you can't use Bioconductor on a ARM64-based Linux machine **now**. I see
>> no reason a priori why you couldn't install (from source) Bioconductor
>> packages on this platform, and use them, as long as:
>>
>>
> Thanks Hervé for a good overview of the issues.  I think there are a couple
> of reasons to keep this dialogue going (and there is now a community slack
> channel
> for further discussion: #arm-linux at community-bioc.slack.com.)
>
> The first reason is Martin's offer of resources to accomplish the support
> aim.  What
> exactly that support aim is remains to be made precise.  As you note, a
> properly
> configured system with R can use BiocManager::install to build from
> source, but
> there are a few additional things that can be done to produce binaries,
> and perhaps
> some of our software in BBS or some of the binary repo generation tools
> could be
> useful for Martin's group to make a relevant binary repo.  The
> package-management
> oriented process of Dirk Eddelbuettel's r2u
> <https://github.com/eddelbuettel/r2u> also seems potentially relevant.
> We also
> have tooling to build all the CRAN dependencies that Bioc packages
> declare.  This
> is all in the open and it would be interesting to see how much work is
> needed to
> get solutions for ARM64 linux.  It could lead to some robustification of
> the existing
> build machinery.  I am not offering to do it, but the fact that all the
> tooling is out in
> the open may not be fully clear and I am just mentioning this.
>
> The second reason to stay engaged is the nature of the ARM platform, which
> is
> said to require lower power consumption for equivalent throughput.  It may
> be
> environmentally beneficial to be ahead of the curve in being able to work
> with
> this platform.  Earlier I linked to a github issue indicating that rocker
> now has a dual
> platform container image including arm64 support but I don't know if that
> really
> addresses the issue at hand. Maybe I need to go onto a graviton machine to
> find out.
>

So I did th

Re: [Bioc-devel] Support for Linux ARM64

[Vincent Carey]

On Thu, Jan 5, 2023 at 1:44 PM Hervé Pagès 
wrote:

> Hi Martin,
>
> Linux runs on many architectures, ARM64 is just one of them.
>
> Our daily builds have traditionally focused on 3 platforms: Intel-based
> Linux (Ubuntu 22.04), Windows, and Intel-based Mac. Note that we
> recently added ARM64-based Mac to our daily builds.
>
> One big difference between Linux and the other platforms is that we only
> produce binary packages for the latter. More precisely:
>
> - on the Linux builders: the daily builds only run 'R CMD INSTALL', 'R
> CMD build', and 'R CMD check', on each Bioconductor package,
>
> - on the Windows and Mac builders: the daily builds run all the above
> plus an additional step that we call the BUILD BIN step that produces a
> binary for each Bioconductor package.
>
> This means that on Linux, as well as on any other Unix-like OS that is
> not macOS (e.g. FreeBSD, OpenBSD, Solaris, HP-UX, etc...), users will
> install all their packages (Bioconductor and CRAN) **from source**. This
> should work as long as they are on a platform where R is supported and
> have the required compilers (C, C++, and Fortran).
>
> Note that if officially supporting a given platform means running the
> daily builds on that particular platform, then there's no way for us to
> do that because platform == OS + architecture, and the list of
> combinations of Unix-like OS's (Linux, FreeBSD, Solaris, etc...) +
> architectures (Intel, ARM64, Sparc, powerpc) is endless. Even if we
> narrow this list to Intel-based Linux, there are hundreds of Linux
> distributions around that use different kernel, compilers, package
> managers, etc...
>
> All this to say that, as far as the daily builds are concerned, we had
> to make choices, and those choices are based on the most commonly used
> platforms. Since all Bioconductor packages are tested daily on
> Intel-based Linux (Ubuntu 22.04), Windows, Intel-based Mac, and
> ARM64-based Mac, we have some reasonable confidence that they will work
> properly on these 4 platforms (still not a 100% guarantee of course,
> there's nothing like that).
>
> My understanding is that ARM64-based Linux is still a marginally used
> platform so probably not worth for us to allocate resources on adding it
> to our daily builds at the moment. If it ever becomes more mainstream in
> the future, then we will certainly reconsider. That does not mean that
> you can't use Bioconductor on a ARM64-based Linux machine **now**. I see
> no reason a priori why you couldn't install (from source) Bioconductor
> packages on this platform, and use them, as long as:
>
>
Thanks Hervé for a good overview of the issues.  I think there are a couple
of reasons to keep this dialogue going (and there is now a community slack
channel
for further discussion: #arm-linux at community-bioc.slack.com.)

The first reason is Martin's offer of resources to accomplish the support
aim.  What
exactly that support aim is remains to be made precise.  As you note, a
properly
configured system with R can use BiocManager::install to build from source,
but
there are a few additional things that can be done to produce binaries, and
perhaps
some of our software in BBS or some of the binary repo generation tools
could be
useful for Martin's group to make a relevant binary repo.  The
package-management
oriented process of Dirk Eddelbuettel's r2u
 also seems potentially relevant.  We
also
have tooling to build all the CRAN dependencies that Bioc packages
declare.  This
is all in the open and it would be interesting to see how much work is
needed to
get solutions for ARM64 linux.  It could lead to some robustification of
the existing
build machinery.  I am not offering to do it, but the fact that all the
tooling is out in
the open may not be fully clear and I am just mentioning this.

The second reason to stay engaged is the nature of the ARM platform, which
is
said to require lower power consumption for equivalent throughput.  It may
be
environmentally beneficial to be ahead of the curve in being able to work
with
this platform.  Earlier I linked to a github issue indicating that rocker
now has a dual
platform container image including arm64 support but I don't know if that
really
addresses the issue at hand. Maybe I need to go onto a graviton machine to
find out.

In any case it is not so often that we get a request for enhancements that
includes
an offer of VMs and person power so I want to be sure we don't lose the
thread
prematurely.







> - R is supported on your ARM64-based Linux machine
>
> - you have compilers that are supported by R
>
> - you have the external libraries that are required by some CRAN and/or
> Bioconductor packages.
>
> Hope this helps,
>
> H.
>
> On 05/01/2023 02:01, Martin Grigorov wrote:
> > Dear community,
> >
> > Happy and successful new year!
> >
> > Appologies if this has been discussed before but
> > https://stat.ethz.ch/pipermail/bioc-devel/ does not provide search
> > 

Re: [Bioc-devel] Bioconductor data packages containing very large files

[Vincent Carey]

I would like us to discuss this in the context of the HDF Scalable Data
Service that we have
running on the NSF cloud in jetstream2.  Let's discuss off line and then
report back to the list.


On Thu, Jan 5, 2023 at 7:11 AM Heery Richard  wrote:

> Thank you Lori.
>
> I was wondering if there is someone I could  ask if what I am working on
> could be of interest and suitable for Bioconductor before investing more
> time developing it and uploading the data? What I have is a HDF5 file
> constructed using the Bioconductor methrix package for all of the
> methylation data for TCGA downloaded from GDC. It allows rapid querying of
> methylation data for regions of interest (e.g. enhancers or promoters)
> provided as a GRanges object across the ~10,000 samples in TCGA, completing
> a pan-cancer analysis in minutes . Otherwise, downloading and querying data
> for regions of interest in several cancer types could take several days or
> longer.
>
> There are already packages for downloading TCGA data on Bioconductor, but
> what I think is novel here is the speed and ease with which methylation
> data can be retrieved for a large number of samples.
>
> Please let me know if this is something that could be useful for
> Bioconductor.
>
> Best wishes,
>
> Richard
> 
> From: Kern, Lori 
> Sent: Wednesday, January 4, 2023 3:22 PM
> To: Heery Richard ; bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: Re: Bioconductor data packages containing very large files
>
> A package cannot be that large directly.  Please see information on
> creating an ExperimentHub package to provide the data for use in the
> package:
>
>
> https://bioconductor.org/packages/release/bioc/vignettes/HubPub/inst/doc/CreateAHubPackage.html
> <
> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fbioconductor.org%2Fpackages%2Frelease%2Fbioc%2Fvignettes%2FHubPub%2Finst%2Fdoc%2FCreateAHubPackage.html=8c00e339=ddd80e7a=y=n
> >
>
> Cheers,
>
>
>
>
> Lori Shepherd - Kern
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of Heery
> Richard 
> Sent: Wednesday, January 4, 2023 9:07 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] Bioconductor data packages containing very large
> files
>
> Hi Bioconductor,
>
> I have made a database that is 27 GB that I would like to share as part of
> a Bioconductor package and I was just wondering if it is possible to submit
> very large files like this to Bioconductor or if there may be any
> alternative ways of sharing the file as part of a package?
>
> Best wishes,
>
> Richard Heery
>
> IEO, Milan, Italy
> [5x1000]<
> http://secure-web.cisco.com/1AxunlkMfMiOLWUzSr4U79PCQR-m5gepMk3mVQ7uLXKMCAeTNzkyygmALFERcsVxhVSX7zkAFcllkjIZnZKxUh80DdGusfFIL4XGxaAJXK-2sG43sKOXakdJVd8cDp7HQArb01uoPUuJlVHlAaVSxuLW-ZABWxKwog7MokYLudEkL7-ib-hPb7R2WajUM6LmVWyXT51DcWzhFVIHJ4LNCbfelON_k_SA2ybm5NUGX7cKNLFpUIW2cmp2rhue-arnJ30_cFqdxWgDzajh8Nt87OFWo51fE4_OyTrtBO-CG555adYVMuYutSliHgvl1_BGs/http%3A%2F%2Fwww.ieo.it%2Fit%2FSCIENCE-IN-SOCIETY%2FLe-nostre-iniziative%2F5-per-mille%2F
> ><
> https://urlsand.esvalabs.com/?u=http%3A%2F%2Fsecure-web.cisco.com%2F1AxunlkMfMiOLWUzSr4U79PCQR-m5gepMk3mVQ7uLXKMCAeTNzkyygmALFERcsVxhVSX7zkAFcllkjIZnZKxUh80DdGusfFIL4XGxaAJXK-2sG43sKOXakdJVd8cDp7HQArb01uoPUuJlVHlAaVSxuLW-ZABWxKwog7MokYLudEkL7-ib-hPb7R2WajUM6LmVWyXT51DcWzhFVIHJ4LNCbfelON_k_SA2ybm5NUGX7cKNLFpUIW2cmp2rhue-arnJ30_cFqdxWgDzajh8Nt87OFWo51fE4_OyTrtBO-CG555adYVMuYutSliHgvl1_BGs%2Fhttp%253A%252F%252Fwww.ieo.it%252Fit%252FSCIENCE-IN-SOCIETY%252FLe-nostre-iniziative%252F5-per-mille%252F%26gt%3B=8c00e339=13a49eac=y=n
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/139fG07AH98RfoK_SoTpu-tcev3I6LbfqnNToVDRGIvCJsmi1AvcbL1c_t7Dd-rZAXrbqZqUyjb-Sim4Tlgxui3zBHM-ntzSY3xE-0nyd4prF3cuito1iGsDjrgMaAqQ35mIgJeRu2NgXkmQYh5E_wUGoyaoiTz5wLOF2f_rz5wXX3QfIIeUKae7OPTyPuN7OoBJ_gqHxxZ0pK0K6ZyHmOqaF5vc7CmBgK26UgmtjXgat8_vjnbfbDbp_rO_0k1IdDLJjIkyBoSdmFO6wmG6H4Y4r1CzG9PyRLXXG8CMX4PHGc4DMXCTsBYxv6T3GOTpW/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
> <
> https://urlsand.esvalabs.com/?u=https%3A%2F%2Fsecure-web.cisco.com%2F139fG07AH98RfoK_SoTpu-tcev3I6LbfqnNToVDRGIvCJsmi1AvcbL1c_t7Dd-rZAXrbqZqUyjb-Sim4Tlgxui3zBHM-ntzSY3xE-0nyd4prF3cuito1iGsDjrgMaAqQ35mIgJeRu2NgXkmQYh5E_wUGoyaoiTz5wLOF2f_rz5wXX3QfIIeUKae7OPTyPuN7OoBJ_gqHxxZ0pK0K6ZyHmOqaF5vc7CmBgK26UgmtjXgat8_vjnbfbDbp_rO_0k1IdDLJjIkyBoSdmFO6wmG6H4Y4r1CzG9PyRLXXG8CMX4PHGc4DMXCTsBYxv6T3GOTpW%2Fhttps%253A%252F%252Fstat.ethz.ch%252Fmailman%252Flistinfo%252Fbioc-devel=8c00e339=11e86087=y=n
> >
>
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible 

Re: [Bioc-devel] Support for Linux ARM64

[Vincent Carey]

On Thu, Jan 5, 2023 at 5:02 AM Martin Grigorov 
wrote:

> Dear community,
>
> Happy and successful new year!
>
> Appologies if this has been discussed before but
> https://stat.ethz.ch/pipermail/bioc-devel/ does not provide search
> facilities and my googling didn't help much!
>
> I'd like to ask whether Linux ARM64 is officially supported ?
> I know that Mac ARM64 is supported since 3.16 [1] [2].
> I cannot find such test results for Linux ARM64 and the site search [3]
> also mentions "arm64" only in context of "macOS".
> In addition the Docker images are also single-platform [4] (linux/amd64).
>
> How can we help to add support for Linux ARM64 ?
> My employer is willing to donate VMs and man power if the community is
> interested in adding support for Linux ARM64!
>

Thanks Martin, very interesting question.  Can you tell us a little more
about basic
support for R for this environment?  I would have to remark that even
expanding our
support to mac ARM was out of scope for our core project, but the demand was
significant.

Superficial searching in response to your question led to

https://github.com/rocker-org/rocker-versioned2/issues/144#issuecomment-1363791740

which suggests to me that we (or you!) could get a dual-platform container
out without
too much hassle.  Would that help meet your need?  Once the container is
produced there
is then the implied requirement that a compatible set of package binaries
is made and
maintained.  That's a place where your offer of machinery and staff time
could be very
beneficial.  We have tooling for binary repository production that should
be re-usable on
that platform.

(Is arm64 linux a build target supported on github actions, by the way?)

This is a pretty specialized topic so I think I will make a slack channel
for it in the
community bioconductor slack and we can carry on the discussion there,
although I am
fine with further discussion here as well.







>
>
> Regards,
> Martin
>
> 1. https://bioconductor.org/news/bioc_3_16_release/
> 2. https://bioconductor.org/checkResults/3.17/bioc-mac-arm64-LATEST/
> 3. https://bioconductor.org/help/search/index.html?q=arm64/
> 4. https://hub.docker.com/r/bioconductor/bioconductor_docker/tags
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Large vignettes

[Vincent Carey]

I am glad you brought this up here, and I welcome further discussion on
this mailing list.  It is important to understand the constraints on
development
that arise from Bioconductor's package guidelines.

I don't think we want to change the limits on package payload size without
understanding the consequences for users and our build system.  The split
approach mentioned by Lambda seems sensible to me, and I hope it is
not too burdensome.  Additional commentary and details from the community
are welcome.

On Wed, Jan 4, 2023 at 3:21 PM Lambda Moses  wrote:

> Hi Adam,
>
> I also got this problem, and I would like some input from Bioc Core
> Team. I worked around it by writing a minimal vignette in the main
> branch. Then I made a documentation branch, where I have the same code
> as in main branch, but with more elaborate vignettes used to build a
> pkgdown website. I made a rule for myself that I can only merge from the
> main or devel branch to the documentation branch but not the other way
> round. I would switch branch when I find a bug or want a new feature
> while writing the vignettes. You can see the main branch here:
> https://github.com/pachterlab/voyager/tree/main The documentation branch
> here: https://github.com/pachterlab/voyager/tree/documentation
>
> I kind of wonder if the 5 MB rule is outdated in the age of increasing
> computer power and internet speed. A jpeg photo can easily exceed 5 MB.
> I also wonder if this rule is deliberately kept for good reasons, like
> to make R more inclusive to disadvantaged people with limited internet
> services.
>
> Regards,
>
> Lambda
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Multiple projects for submission to Bioconductor

[Vincent Carey]

On Mon, Jan 2, 2023 at 7:51 PM Ali Sajid Imami 
wrote:

> Hi Colleagues,
>
> I am currently a PhD student in Bioinformatics at the University of Toledo,
> College of Medicine and Life Sciences. I am working in the cognitive
> disorders research lab (https://cdrl-ut.org) and we have been actively
> developing multiple packages. We are particularly interested in
> building data and analysis packages for Kinase Activity analysis.
>
> We have a number of packages that we would like to submit to Bioconductor
> for acceptance. I am currently in the process of streamlining the packages,
> making sure their dependencies are clearly defined and extracting large
> datasets into their own data packages.
>
> I had a couple of questions regarding the submissions:
>
> 1. At our lab we rely heavily on Github Actions for continuous integration
> and delivery. Are the actions outlined in the biocthis (
> https://bioconductor.org/packages/release/bioc/html/biocthis.html) package
> up to date and something we can reliably build on?
>

Thank you for your note.

I would say the answer here is "yes", but you could also check with the
author of biocthis to see whether there are any concerns to be aware of.


> 2. We have quite a few packages and there may be some packages that would
> be better to go into the same release. Is it possible to submit them all
> separately but have their review process be streamlined, collectively?
>

It is impossible to say without more information.  We have limited personnel
for reviewing.  There is an approach for submitting related packages, see
here
<https://github.com/Bioconductor/Contributions/blob/master/CONTRIBUTING.md#submitting-related-packages>
.

3. Is Bioconductor's git infrastructure set up to update from our github
> repo or is there a solution we can build to push our new "release" to the
> bioconductor git infra after the integration tests in github actions are
> completed?
>

I suspect you could accomplish update-git-on-push-to-github but perhaps
further discussion is needed.  At this time our build system works with git
repositories that are jointly managed by us and by the package maintainer.
Maintainers are responsible for ensuring that the git repository is up to
date.

Sincerely,
Vincent Carey


> Thank you.
>
>
> Regards,
> Dr. Ali Sajid Imami
> LinkedIn <https://pk.linkedin.com/pub/ali-sajid-imami/50/956/2a6>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Package "rmspc" failing on Bioconductor devel

[Vincent Carey]

At this time (and for the foreseeable future) messaging on changes to
packages
only occurs during the review process.  Your version 1.5.1 is visible in
git and will be
tested in the next build cycle which should be very soon.   Thank you

On Wed, Dec 28, 2022 at 12:29 PM Meriem Bahda  wrote:

> Dear Community,
>
> I have recently submitted a new version of the package rmspc to
> Bioconductor in order to update it.
> However, when I pushed the changes to the Bioconductor and GitHub
> repositories, nothing happened (I didn't receive a message saying a new
> build has been started (like I used to before).
>
> To give you some context, the current devel version of the package is 1.5.0
> and I bumped the version of the package to 1.5.1. Did I miss something?
>
> Thank you very much,
>
> --
>
> *Meriem BAHDA*
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Developing a package that handle BAM file

[Vincent Carey]

On Sun, Dec 18, 2022 at 4:07 PM Hao Feng  wrote:

> Hi Bioconductor team,
>
> We’re developing a package to analyze a `new` type of high-throughput
> sequencing data. We have some BAM files ready. We’d like the package to be
> able to take BAM files as the input. In addition, to maintain our method’s
> statistical rigor, we’d like to implement repeated sampling for multiple
> times (a large number).
>
> This brings concern to a package development, which I’d like to collect
> some feedback prior to proceed:
> 1. The best practice to use BAM files as the example data? BAM files are
> large in general. Although we can use a part of the BAM, instead of the BAM
> from the whole genome, as the example data, I still don’t think it’s
> feasible to include those external files in the package submission. And due
> to the novelty of this sequencing experiment, I don’t think the current
> experiment data packages have them. Would you suggest us submitting a new
> experiment data package (of several dozen MBs), along with our software
> package?


Yes


>
> 2. Deal with long example run time? Due to repeated sampling and the
> handling of BAM files, we suspect our software code examples may take a
> long running time. Do you have any suggestions on this so it can pass the
> software checking, which is time-bound?
>

https://contributions.bioconductor.org/long-tests.html

We will be happy to help you through any technical obstacles you encounter
in preparing either
the experiment data submission or the long testing situation.

Thank you


>
> Thank you very much in advance.
>
>
>
>
> Regards,
> Hao
>
>
> ---
> Hao Feng, Ph.D.
> Assistant Professor in Biostatistics
> Department of Population and Quantitative Health Sciences
> Case Western Reserve University School of Medicine
> Harland Wood Building - Room WG-82T
> 10900 Euclid Avenue
> SOM / Room G82T
> Cleveland, OH 44106-4945
> Phone: 216-368-5510
> Lab website: https://hfenglab.org/
> Official website: http://epbiwww.case.edu/haofeng-phd/
> Email: hxf...@case.edu 
>
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Flexibility for submitting a new ExperimentData-package

[Vincent Carey]

Thank you for this note.  We cannot modify the system to accept this
package.  If we can help with aspects
of compatibility problems related to ExperimentHub let us know.

On Thu, Nov 24, 2022 at 1:58 AM Daniel Laajala  wrote:

> Dear Bioconductor devs,
>
> thanks for all the hard work. Regarding if there's any leeway in how
> ExperimentData-packages are structured:
>
> We started working a few years back on a "curatedPCaData" R-package for
> curating prostate cancer multi-'omics datasets. We followed the structure
> of a family of similar packages, e.g. readily on bioc:
>
> https://bioconductor.org/packages/release/data/experiment/html/curatedBreastData.html
>
> https://bioconductor.org/packages/release/data/experiment/html/curatedOvarianData.html
>
> With the data in a satisfactory form, we were now hoping to submit the
> package to Bioconductor. However, due to the size of
> MultiAssayExperiment-objects, the package is auto-rejected:
> https://github.com/Bioconductor/Contributions/issues/2804
>
> The data-raw/-files we can discard, as we provided these just for extra
> user convenience.
> However, the mae_*.rda files are essential MultiAssayExperiment objects
> (as a standard format for multi-'omics in Bioc), but these are right now
> too large for the bot.
>
> Reading the package structure instructions, we were under the impression
> that this old structure for ExperimentData would still be ok for
> Bioconductor; the package passed checks (R CMD check and BiocCheck) with
> minor NOTEs. Our current GitHub is at:
> https://github.com/Syksy/curatedPCaData
>
> Our package already has citations (with code provided there-in for
> extracting and processing relevant data from the package), has been forked,
> has collaborators using it as-is, etc, so revamping it to e.g.
> ExperimentHub-structure would most likely cause quite major compatibility
> issues.
>
>
> Would there be any chance of approaching Bioconductor with the package
> roughly in its current format inspired by these older curated-packages,
> even if it is not in the updated ideal ExperimentData-format?
>
> Kind regards,
> Teemu Daniel Laajala
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Fwd: Package "SingleCellSignalR" failing on Bioconductor devel

[Vincent Carey]

When testing on the devel branch at this time, you must use R-devel (R
4.3).   See https://contributions.bioconductor.org/use-devel.html#use-devel

For SingleCellSignalR, the dependence on SIMLR seems problematic.  SIMLR is
in an error state on the devel branch.  One
could see that even in the release branch, SIMLR includes some code that is
risky:

* installing to library ‘/home/biocbuild/bbs-3.16-bioc/R/library’
* installing *source* package ‘SIMLR’ ...
** using staged installation
** libs
g++ -std=gnu++14 -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include'
-I/usr/local/include   -fpic  -g -O2  -Wall -c RcppExports.cpp -o
RcppExports.o
g++ -std=gnu++14 -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include'
-I/usr/local/include   -fpic  -g -O2  -Wall -c Rtsne.cpp -o Rtsne.o
gcc -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include'
-I/usr/local/include   -fpic  -g -O2  -Wall -c package_init.c -o
package_init.o
gcc -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include'
-I/usr/local/include   -fpic  -g -O2  -Wall -c projsplx_R.c -o
projsplx_R.o
g++ -std=gnu++14 -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include'
-I/usr/local/include   -fpic  -g -O2  -Wall -c sptree.cpp -o sptree.o
g++ -std=gnu++14 -I"/home/biocbuild/bbs-3.16-bioc/R/include" -DNDEBUG
-I'/home/biocbuild/bbs-3.16-bioc/R/library/Rcpp/include'
-I/usr/local/include   -fpic  -g -O2  -Wall -c tsne.cpp -o tsne.o
tsne.cpp: In member function ‘bool TSNE::load_data(double**, int*,
int*, int*, double*, double*, int*)’:
tsne.cpp:967:48: warning: comparison of integer expressions of
different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’
[-Wsign-compare]
  967 |   if (fread(*data, sizeof(double), *n * *d, h) != *n * *d) {
  |   ~^~


but it passed on the release branch.  On the devel branch SIMLR fails.
The sources for

SIMLR don't appear to have changed since 2017 (reading git log).  So
this seems like a situation

in which a package that has not changed since release fails in devel because

the tolerance of the build system for compiler-flagged warning events
has been reduced.

The developers of SIMLR will need to fix this, or you will have to
eliminate the dependence on

SIMLR from your package.  Your favorable results for CMD check arise
from a) not working

in the devel branch and b) having a version of SIMLR that built under
out-of-date warning

tolerance compiler settings.  Let us know if there are further questions.




On Sat, Nov 26, 2022 at 6:15 AM Jacques Colinge <
jacques.coli...@umontpellier.fr> wrote:

> Dear Johannes,
> Dear Bioc Developers,
>
> I am not sure I get the problem. I am currently running R 4.2.1 and if I
> do a devtools::check() and a devtools::build() I have no error (just one
> warning), see below both outputs.
>
> Do you need me to install R development version and redo those tests
> because with this new versions some errors occur?
>
> Thanks for your answer.
> Best regards,
> Jacques
>
> --- check() output -
>
> jcolinge@osboxes:~/SingleCellSignalR$ R
>
> R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
> Copyright (C) 2022 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
>Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
>  > library(devtools)
> Loading required package: usethis
>  > devtools::check()
> ══ Documenting
>
> ═
> ℹ Installed roxygen2 version (7.2.1) doesn't match required (7.0.2)
> ✖ `check()` will not re-document this package
> ══ Building
>
> 
> Setting env vars:
> • CFLAGS: -Wall -pedantic -fdiagnostics-color=always
> • CXXFLAGS  : -Wall -pedantic -fdiagnostics-color=always
> • CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always
> • CXX14FLAGS: -Wall -pedantic -fdiagnostics-color=always
> • CXX17FLAGS: -Wall -pedantic -fdiagnostics-color=always
> • CXX20FLAGS: -Wall -pedantic -fdiagnostics-color=always
> ✔  checking for file ‘/home/jcolinge/SingleCellSignalR/DESCRIPTION’ ...
> ─  

Re: [Bioc-devel] CTCF annotation package's vignette not updating

[Vincent Carey]

Maybe I am wrong Mikhail but I think you have about 6 months to enhance the
documentation of your package in 3.16.

On Sun, Oct 30, 2022 at 7:54 PM Mikhail Dozmorov 
wrote:

> Hello,
> I'm trying to update documentation for the
> https://bioconductor.org/packages/devel/data/annotation/html/CTCF.html
> package so it can be shown in the 3.16 release. Pushed to bioc master
> twice, with version bump. But the build is not triggered
> https://bioconductor.org/checkResults/3.16/data-annotation-LATEST/CTCF/.
> It
> may be due to the 3.16 release schedule or something very simple, but I'm
> trying to meet the October 31 1:30 pm EST deadline and running out of ideas
> what to do to update the package.
> Thanks,
> Mikhail
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Increase version of system dependency?

[Vincent Carey]

My suggestion is that your interfaces to python be mediated with the
basilisk package.  Please
contact me off line if you need assistance; see BiocSklearn for an example;
I am sure there are
others.

On Tue, Oct 18, 2022 at 12:31 PM Sarvesh Nikumbh 
wrote:

> Hi bioc team,
>
> My package seqArchR though does not error in any way, but can spit out
> numerous warnings (originally from Python/scikit-learn which is a
> dependency) depending on the version of  scikit-learn available. This fills
> the output to the extent that it is unreadable. The cause for this is the
> deprecation/future version warning in NMF/scikitlearn
> <
> https://scikit-learn.org/stable/modules/generated/sklearn.decomposition.NMF.html
> >
> which is forced, so I cannot suppress it.
>
> I pushed a fix for this in the devel version -- where, instead of
> increasing the dependency version, I check the module version using
> packaging module from setuptools and appropriately make the python function
> call. But this gives an error on the Windows build machine, and is fine on
> Linux/macOS.
> See
>
> https://bioconductor.org/checkResults/3.16/bioc-LATEST/seqArchR/palomino4-checksrc.html
>
> I expected that setuptools will be available on all machines, because the
> previous alternative, distutils, is available with vanilla python, but is
> not recommended.
>
> Would you suggest having setuptools in the SystemRequirements or using
> distutils?
> Or simply depending on higher version of scikit-learn (the latest 1.2) --
> which is the root cause of this issue anyway.
>
> Thanks and best,
>   Sarvesh
>
> --
>
> thanks!
> -Sarvesh
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Version number trouble

[Vincent Carey]

Hi Mirko -- the devel branch has an odd y in x.y.z

stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES$ cd BindingSiteFinder
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ grep Version DE*
Version: 1.3.0
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git fetch --all
Fetching origin

The current release branch has an even y in x.y.z

stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git checkout
RELEASE_3_15
Branch 'RELEASE_3_15' set up to track remote branch 'RELEASE_3_15' from
'origin'.
Switched to a new branch 'RELEASE_3_15'
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ grep Version DE*
Version: 1.2.0
stvjc@stvjc-XPS-13-9300:~/BIOC_SOURCES/BindingSiteFinder$ git remote -v
origin g...@git.bioconductor.org:packages/BindingSiteFinder (fetch)
origin g...@git.bioconductor.org:packages/BindingSiteFinder (push)

By managing the current checkout you can make changes in a selected branch,
incrementing z in x.y.z in the associated DESCRIPTION file as necessary

Full details at
https://contributions.bioconductor.org/git-version-control.html

On Mon, Oct 10, 2022 at 12:19 PM Brüggemann, Mirko <
mirko.brueggem...@bmls.de> wrote:

> Hello,
>
> I’m having some troubles updating my package(BindingSiteFinder) on the
> devel branch.
>
> I’ve made some changes to the code and as always incremented the z part of
> the version number. Then I realized that the y part of the version number
> was already changed by the Bioconductor team (to 1.3.0). I guess in
> preparation for the new release. So, I left the version number like this,
> to not mess things up.
>
> Now my package does compile without errors or warnings, but my changes do
> not show on the devel landing page. Also, I still want to push some more
> changes prior to the upcoming release.
>
> My question is how do I properly set the version numbers here? Do I keep
> it with the y part set to the new release and then increment the z part (so
> 1.3.0 to 1.3.1?), or do I go back to the lates version number? Since I did
> not push any changes in the last cycle it would then be 1.2.1. And if I do
> will the package still build in the new release?
>
> Maybe someone knows what to do here?
>
> Thanks a lot in advance
> Mirko
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] CITEViz Package Submission Not Building Inbox

[Vincent Carey]

Hi Garth.  I can see 0.99.4 ... Your package has not been subjected to
pre-check yet because of the needs interop label.  I will add comments on
the issue for your package.  I think pre-check will pass soon and then it
will be ingested for build and review later this week.

On Sun, Oct 9, 2022 at 2:27 AM Garth Kong  wrote:

>  Hi BioConductor,
>
> I am currently submitting CITEViz to BioConductor and I may have a
> misunderstanding of how bioconductor's git work. I'm looking for some
> guidance/explanation on why my commits aren't triggering a build. I have
> been following the new package workflow
> <
> https://contributions.bioconductor.org/git-version-control.html#new-package-workflow
> >
> vignette closely and have the following set up for origin and upstream:
>
>
>
>
> *origin  g...@github.com:maxsonBraunLab/CITEViz.git (fetch)origin
>  g...@github.com:maxsonBraunLab/CITEViz.git (push)upstream
>  g...@git.bioconductor.org:packages/CITEViz.git (fetch)upstream
>  g...@git.bioconductor.org:packages/CITEViz.git (push)*
>
> When I version bump (e.g. from 0.99.1 to 0.99.2) and push a new commit to
> bioconductor's git, I realized a build couldn't be triggered in the issues
> page . When I
> `git clone` the upstream to a different folder and do a git log, I am able
> to detect the change:
>
>
>
>
>
> *commit 49e353cf142c71b056ad185963cebacb1df513df (HEAD -> master,
> origin/master, origin/HEAD)Author: gartician  >Date:   Sat Oct 8 23:00:34 2022 -0700version
> bump to 0.99.4*
>
> I think this is odd because I can track the changes in bioconductor's git,
> but the builds aren't triggered. I very much likely have a misunderstanding
> of how things work, so any explanations would be greatly appreciated. Thank
> you for looking into this.
>
>
> --
> Garth Kong
> M.S. in Bioinformatics and Genomics
> Website:https://gartician.github.io/ 
> LinkedIn: https://www.linkedin.com/in/garth-kong/
> GitHub: https://github.com/gartician
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Mac ARM64 binaries available

[Vincent Carey]

We are not running check on ARM platform at this time.  If you want to
provide a link to the
package/error you are having trouble with I will have a look on my
machine.  If you are passing
on the other platforms there will be no consequences for remaining in the
bioc ecosystem.

On Tue, Oct 4, 2022 at 5:22 AM Ramon Diaz-Uriarte  wrote:

> Dear All,
>
> It is unclear to me if the deadline of 28-October-2022 for "packages
> passing ‘‘R CMD build’’ and ‘‘R CMD check’’ without errors or warnings" (
> https://bioconductor.org/developers/release-schedule/) also applies to
> this platform.
>
> Why the question? I am trying to debug an error in this platform of a
> package I maintain but:
>
> a) the snapshot date seems older than the snapshot date in
> http://bioconductor.org/checkResults/devel/bioc-LATEST/ (which would
> introduce a longer delay in verifying results of code changes)
>
> b) results are not linked from the former page (which, I understand, is
> the "canonical" one for checking status).
>
>
> Thanks,
>
>
> R.
>
>
>
> On Tue, 27-September-2022, at 19:46:01, Jennifer Wokaty <
> jennifer.wok...@sph.cuny.edu> wrote:
> > Mac ARM64 binaries are now available. You can view the build report at
> > https://bioconductor.org/checkResults/3.16/bioc-mac-arm64-LATEST/.
> >
> > To make use of these binaries
> >
> > * Install R-4.2.1-arm64.pkg from CRAN at
> https://cran.r-project.org/bin/macosx/
> > * Install BiocManager as usual
> > * Use BiocManager::install() as usual
> >
> > Note: BiocManager::install() will automatically pick the new arm64
> binaries so
> > you should no longer need Xcode.
> >
> >
> > Jennifer Wokaty
> > they/them
> > Bioconductor Core Team
> > CUNY SPH
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> --
> Ramon Diaz-Uriarte
> Department of Biochemistry, Lab B-31
> Facultad de Medicina
> Universidad Autónoma de Madrid
> Arzobispo Morcillo, 4
> 28029 Madrid
> Spain
>
> Phone: +34-91-497-2412
>
> Email: rdia...@gmail.com
>r.d...@uam.es
>
> https://ligarto.org/rdiaz
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] [External] Re: error in bioconductor package DSS

[Vincent Carey]

personally i do not use cherry-pick and perhaps others will comment on its
role

i would git checkout RELEASE_3_15

make change to vignette

git commit
git push

On Fri, Sep 30, 2022 at 6:12 PM Wu, Hao  wrote:

> Okay, after some quick search, I did
>
>
>
> git checkout RELEASE_3_15
>
> git cherry-pick master
>
> git push
>
>
>
> Is this what I should do?
>
>
>
> *From: *"Wu, Hao" 
> *Date: *Friday, September 30, 2022 at 6:08 PM
> *To: *Vincent Carey 
> *Cc: *"bioc-devel@r-project.org" , Harry Feng <
> hxf...@case.edu>
> *Subject: *Re: [External] Re: [Bioc-devel] error in bioconductor package
> DSS
>
>
>
> Vince,
>
>
>
> Thanks for the prompt reply. Can you provide more instruction on how I
> should look at a particular branch and commit the changes to that? When I
> do git clone, what branch did I get?
>
>
>
> Hao
>
>
>
>
>
> *From: *Vincent Carey 
> *Date: *Friday, September 30, 2022 at 6:06 PM
> *To: *"Wu, Hao" 
> *Cc: *"bioc-devel@r-project.org" , Harry Feng <
> hxf...@case.edu>
> *Subject: *[External] Re: [Bioc-devel] error in bioconductor package DSS
>
>
>
> I don't think you are looking at the RELEASE_3_15 branch, but that is
> where the error is occurring.
>
>
>
> On Fri, Sep 30, 2022 at 6:03 PM Wu, Hao  wrote:
>
> Hello,
>
> I recently received an email regarding an error for DSS:
> https://bioconductor.org/checkResults/3.15/bioc-LATEST/DSS/palomino3-buildsrc.html
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbioconductor.org%2FcheckResults%2F3.15%2Fbioc-LATEST%2FDSS%2Fpalomino3-buildsrc.html=05%7C01%7Chao.wu%40emory.edu%7C02fb9e1ebad54540b2b208daa32ffe73%7Ce004fb9cb0a4424fbcd0322606d5df38%7C0%7C0%7C638001723811885161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=H3Em1Xm13tkGjw7b2%2FJP1OQtj4Gcv7OqIf8GwrCJgTM%3D=0>.
> The error is about the parallel computing in Windows. However, I have
> corrected this error a while ago, and it has passed the compilation before.
> It’s not clear why the error appeared again, since in the source code on
> bioconductor, the error shouldn’t be there.
>
> To be more specific, the message says that the error happened in line
> 338-340 in the vignette (DSS.Rmd):
>
> Quitting from lines 338-340 (DSS.Rmd)
> Error: processing vignette 'DSS.Rmd' failed with diagnostics:
> Shrinkage estimator in parallel computing encountered errors. Please
> switch to single core.
>
> However, if I do “git clone g...@git.bioconductor.org:packages/DSS g...@git.bioconductor.org:packages/DSS>” to get the DSS source code, you
> can see lines 338-340 in DSS.Rmd are commented out. It seems the system is
> still compiling the old version. I’m very confused. Could someone help?
>
> Thank you very much.
>
> Hao Wu
>
>
> --
> Professor
> Department of Biostatistics and Bioinformatics
> Rollins School of Public Health
> Emory University
> 1518 Clifton Rd., NE
> Atlanta, GA 30322
> Phone: (404)727-8633
> Fax: (404)727-1370
> Web: http://haowulab.org
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaowulab.org%2F=05%7C01%7Chao.wu%40emory.edu%7C02fb9e1ebad54540b2b208daa32ffe73%7Ce004fb9cb0a4424fbcd0322606d5df38%7C0%7C0%7C638001723812041382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=LKekKN009MoPtjO2WM5iTsQtjqeXQrp1fUKvkBWkLPk%3D=0>
> <http://haowulab.org/
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaowulab.org%2F=05%7C01%7Chao.wu%40emory.edu%7C02fb9e1ebad54540b2b208daa32ffe73%7Ce004fb9cb0a4424fbcd0322606d5df38%7C0%7C0%7C638001723812041382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=LKekKN009MoPtjO2WM5iTsQtjqeXQrp1fUKvkBWkLPk%3D=0>
> >
> Zoom: https://zoom.us/j/8294730806
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzoom.us%2Fj%2F8294730806=05%7C01%7Chao.wu%40emory.edu%7C02fb9e1ebad54540b2b208daa32ffe73%7Ce004fb9cb0a4424fbcd0322606d5df38%7C0%7C0%7C638001723812041382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=yup2fQyHnnid5Cjlqs0nKy1og%2BiZe6DX5yL055mxktw%3D=0>
>
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel=05%7C01%7Chao.wu%40emory.edu%7C02fb9e1ebad54540b2b208daa32ffe73%7Ce004fb9cb0a44

Re: [Bioc-devel] error in bioconductor package DSS

[Vincent Carey]

I don't think you are looking at the RELEASE_3_15 branch, but that is where
the error is occurring.

On Fri, Sep 30, 2022 at 6:03 PM Wu, Hao  wrote:

> Hello,
>
> I recently received an email regarding an error for DSS:
> https://bioconductor.org/checkResults/3.15/bioc-LATEST/DSS/palomino3-buildsrc.html.
> The error is about the parallel computing in Windows. However, I have
> corrected this error a while ago, and it has passed the compilation before.
> It’s not clear why the error appeared again, since in the source code on
> bioconductor, the error shouldn’t be there.
>
> To be more specific, the message says that the error happened in line
> 338-340 in the vignette (DSS.Rmd):
>
> Quitting from lines 338-340 (DSS.Rmd)
> Error: processing vignette 'DSS.Rmd' failed with diagnostics:
> Shrinkage estimator in parallel computing encountered errors. Please
> switch to single core.
>
> However, if I do “git clone g...@git.bioconductor.org:packages/DSS g...@git.bioconductor.org:packages/DSS>” to get the DSS source code, you
> can see lines 338-340 in DSS.Rmd are commented out. It seems the system is
> still compiling the old version. I’m very confused. Could someone help?
>
> Thank you very much.
>
> Hao Wu
>
>
> --
> Professor
> Department of Biostatistics and Bioinformatics
> Rollins School of Public Health
> Emory University
> 1518 Clifton Rd., NE
> Atlanta, GA 30322
> Phone: (404)727-8633
> Fax: (404)727-1370
> Web: http://haowulab.org
> Zoom: https://zoom.us/j/8294730806
>
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] groHMM package error check report error

[Vincent Carey]

There are .o and .so files in /src in the repo.  These should not be
present in any source package.  Please
remove them.

On Sat, Sep 24, 2022 at 6:58 AM Tulip Nandu 
wrote:

> Hi,
>
> I received the following email,
> "According to the Multiple platform build/check report for BioC 3.16,
> the groHMM package has the following problem(s):
>
>   o ERROR for 'R CMD check' on nebbiolo2. See the details here:
>
> https://master.bioconductor.org/checkResults/3.16/bioc-LATEST/groHMM/nebbiolo2-checksrc.html
>
>   o ERROR for 'R CMD INSTALL' on nebbiolo2. See the details here:
>
> https://master.bioconductor.org/checkResults/3.16/bioc-LATEST/groHMM/nebbiolo2-install.html
>
> Please take the time to address this by committing and pushing
> changes to your package at git.bioconductor.org
>
> Notes:
>
>   * This was the status of your package at the time this email was
> sent to you.
> Given that the online report is updated daily (in normal
> conditions) you
> could see something different when you visit the URL(s) above,
> especially if
> you do so several days after you received this email.
>
>   * It is possible that the problems reported in this report are false
> positives,
> either because another package (from CRAN or Bioconductor) breaks
> your
> package (if yours depends on it) or because of a Build System
> problem.
> If this is the case, then you can ignore this email.
>
>   * Please check the report again 24h after you've committed your
> changes to the
> package and make sure that all the problems have gone.
>
>   * If you have questions about this report or need help with the
> maintenance of your package, please use the Bioc-devel mailing
> list:
>
>   https://bioconductor.org/help/mailing-list/
>
> (all package maintainers are requested to subscribe to this list)
>
> For immediate notification of package build status, please
> subscribe to your package's RSS feed. Information is at:
>
> https://bioconductor.org/developers/rss-feeds/
>
> Thanks for contributing to the Bioconductor project!
>
> CAUTION: This email originated from outside UTSW. Please be cautious
> of links or attachments, and validate the sender's email address before
> replying."
>
>
>
> When I checked at my end, the groHMM package is being installed correctly
> without any problems. Can you check again if there is an issue and if all
> dependencies are installed correctly?
>
> Let me know.
>
> Regards,
>
> Tulip.
>
>
> 
>
> UT Southwestern
>
> Medical Center
>
> The future of medicine, today.
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

[Bioc-devel] apps for overviews of adverse bioc package building events

[Vincent Carey]

some code has been written and put in a shiny app to help drill down
to those packages in the BIoc build system that are exhibiting errors
or warning at various stages of the install/build/check process

https://vjcitn.shinyapps.io/biocPkgState316/

https://vjcitn.shinyapps.io/biocPkgState315/

startup can be slow.

some details are available at associated pkgdown site:

https://vjcitn.github.io/bbsBuildArtifacts/index.html

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

[Bioc-devel] Fwd: Package fails to install

[Vincent Carey]

I forgot to reply all.  Here is my initial response.

-- Forwarded message -
From: Vincent Carey 
Date: Wed, Jul 27, 2022 at 8:20 AM
Subject: Re: [Bioc-devel] Package fails to install
To: Alemu Takele 




On Wed, Jul 27, 2022 at 8:13 AM Alemu Takele  wrote:

> Hi the Bioconductor community,
>
> I have submitted and published a package called SPsimSeq on Bioconductor
> but I'm having an issue of installing it using the command
> `BiocManager::install("SPsimSeq"). Apparently, I'm not the only one with
> this issue. When I run the above command, the error message says
>

Thanks for your note.  You are using Bioconductor 3.12, but the current
version is 3.15.
You can continue with 3.12 but you will have to acquire compatible versions
of all the
non-BioC dependencies like latticeExtra... you may need to find an earlier
version; see

https://support.rstudio.com/hc/en-us/articles/219949047-Installing-older-versions-of-packages



> > BiocManager::install("SPsimSeq")
> Bioconductor version 3.12 (BiocManager 1.30.10), R 4.0.3 (2020-10-10)
> Installing package(s) 'SPsimSeq'
> trying URL '
> https://bioconductor.org/packages/3.12/bioc/bin/windows/contrib/4.0/SPsimSeq_1.0.0.zip
> '
> Content type 'application/zip' length 911693 bytes (890 KB)
> downloaded 890 KB
>
> package ‘SPsimSeq’ successfully unpacked and MD5 sums checked
>
>
> Then
> > library(SPsimSeq)
> Error: package or namespace load failed for ‘SPsimSeq’ in loadNamespace(j
> <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]):
>  there is no package called ‘latticeExtra’
> In addition: Warning message:
> In readRDS(f) : error reading the file
>
>
> The package 'latticeExtra' is not part of SPsimSeq dependencies and when I
> try to install I never succeed.
>
> Can you suggest to me the solution, please? Thanks in advance.
>
>
> Best regards,
>
> Alemu Takele, ASSEFA
> Tel: +32 486 76 84 55
> Skype: Alemu.tak
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Bioconductor install instructions for M1-based Mac

[Vincent Carey]

Thanks Gordon, I agree that some documentation should be added.  While
we are not in a position to provide
binaries for M1 at this time, anyone who has prepared their
M1-oriented version of R to install packages from source
can install Bioconductor packages.  I will respond on the support
site, and we will work on enhancing the
documentation for users.

On Sat, Feb 19, 2022 at 7:00 PM Gordon Smyth  wrote:
>
> Given all the questions on the Bioc Support forum, it would be timely to have 
> guidance on the Bioconductor install page:
>
>   https://www.bioconductor.org/install/
>
> for users with an M1-based Mac. As far as I know, there isn't any 
> documentation alerting a beginner user that Bioconductor doesn't support the 
> native M1 compilation of R.
>
> Thanks
> Gordon
>
> --
> Professor Gordon K Smyth
> Joint Head, Bioinformatics Division
>
> [WEHI Logo]
>
>
> Walter and Eliza Hall Institute of Medical Research
> 1G Royal Parade Parkville Victoria 3052 Australia
>
> www.wehi.edu.au
>
> Twitter  |  
> Facebook  |  
> Instagram  |  
> Youtube  |  
> LinkedIn
>
>
> WEHI acknowledges the Wurundjeri people of the Kulin Nation as the 
> traditional owners of the land where our campuses are located and the 
> continuing connection to country and community.
>
> Private and confidential
> The content of this e-mail and any attachments may be private and 
> confidential, intended only for use of the individual or entity named. If you 
> are not the intended recipient of this message you must not read, forward, 
> print, copy, disclose, use or store in any way the information this e-mail or 
> any attachment contains. If you are not the intended recipient, please notify 
> the sender immediately and delete or destroy all copies of this e-mail and 
> any attachment.
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
The information in this e-mail is intended only for the ...{{dropped:16}}

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

Re: [Bioc-devel] Git recognizes me but denies access

[Vincent Carey]

How are we doing with this?  Can destiny be maintained?  Do we need more
git assistance?
I am told the package is not passing check in 3.14.

On Thu, Nov 18, 2021 at 4:24 AM Philipp A.  wrote:

> My addresses are phil.ange...@gmail.com (not philipp) and
> flying-sh...@web.de.
>
> I’ll add a key as soon as I’m able to log in.
>
> Am Mo., 15. Nov. 2021 um 15:56 Uhr schrieb Nitesh Turaga <
> nturaga.b...@gmail.com>:
>
> > You have to activate the account at
> > https://git.bioconductor.org/BiocCredentials/account_activation. Set a
> > password and add Ssh keys.
> >
> > Once again, the email you are trying to activate is '
> > philipp.ange...@gmail.com’.
> >
> > The problem seems to be non-matching key pairs. Add new SSH keys.
> >
> > Best,
> >
> > Nitesh
> >
> >
> > Nitesh Turaga
> > Scientist II, Department of Data Science,
> > Bioconductor Core Team Member
> > Dana Farber Cancer Institute
> >
> > > On Nov 15, 2021, at 9:54 AM, Nitesh Turaga 
> > wrote:
> > >
> > > Hi Philipp,
> > >
> > > The email address that is registered to BiocCredentials right now is '
> > philipp.ange...@gmail.com'. It doesn’t look like an institutional email
> > address.
> > >
> > > Could you please confirm the email change to flying-sh...@web.de ??
> > >
> > > Best,
> > >
> > > Nitesh
> > >
> > > Nitesh Turaga
> > > Scientist II, Department of Data Science,
> > > Bioconductor Core Team Member
> > > Dana Farber Cancer Institute
> > >
> > >> On Nov 15, 2021, at 2:36 AM, Carsten Marr <
> > carsten.m...@helmholtz-muenchen.de> wrote:
> > >>
> > >> confirmed!
> > >>
> > >>
> > >> best,
> > >> c
> > >>
> > >>
> > >>
> > >>> Am 13.11.2021 um 15:56 schrieb Philipp A. :
> > >>>
> > >>> I no longer have control of this email address.
> > >>>
> > >>> Please add the one I’m writing from to the account.
> > >>>
> > >>> My supervisor (CC) from when I was at the institution can confirm
> that
> > I’m the same person.
> > >>>
> > >>> Best, Phil
> > >>>
> > >>> Am Di., 9. Nov. 2021 um 16:24 Uhr schrieb Nitesh Turaga <
> > nturaga.b...@gmail.com>:
> > >>> Dear Phil,
> > >>>
> > >>> Please activate your account at
> > https://git.bioconductor.org/BiocCredentials/account_activation. Add new
> > SSH keys, because it’s possible you are not using the correct key-pairs.
> > >>>
> > >>> Nothing on our end seems out of place.
> > >>>
> > >>> The FAQ section from #13 onwards has other debugging options as well,
> > https://bioconductor.org/developers/how-to/git/faq/.
> > >>>
> > >>> Best,
> > >>>
> > >>> Nitesh
> > >>>
> > >>>
> > >>> Nitesh Turaga
> > >>> Scientist II, Department of Data Science,
> > >>> Bioconductor Core Team Member
> > >>> Dana Farber Cancer Institute
> > >>>
> >  On Nov 8, 2021, at 12:23 PM, Philipp A. 
> wrote:
> > 
> >  Hi,
> > 
> >  My package (destiny) has been deprecated because Bioconductor’s
> LaTeX
> >  environment keeps changing and breaking my docs.
> > 
> >  I‘m trying to fix it once again, but I get:
> > 
> >  $ git push upstream masterFATAL: W any packages/destiny p.angerer
> >  DENIED by fallthru
> > 
> >  *Please note that this isn’t covered in the FAQ*:
> > 
> >  “p.angerer” indicates that it recognizes me, but still doesn’t allow
> > me to
> >  push commits.
> > 
> >  Best, Phil
> > 
> >   [[alternative HTML version deleted]]
> > 
> >  ___
> >  Bioc-devel@r-project.org mailing list
> >  https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > >>>
> > >>
> > >> ---
> > >> Carsten Marr
> > >> +49 89 3187 2158
> > >> AIH Institute of AI for Health
> > >> Helmholtz Zentrum München
> > >> www.helmholtz-muenchen.de/aih/index.html
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Helmholtz Zentrum München
> > >> Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
> > >> Ingolstädter Landstr. 1
> > >> 85764 Neuherberg
> > >> www.helmholtz-muenchen.de
> > >> Aufsichtsratsvorsitzende: MinDir.in Prof. Dr. Veronika von Messling
> > >> Geschäftsführung: Prof. Dr. med. Dr. h.c. Matthias Tschöp, Kerstin
> > Günther
> > >> Registergericht: Amtsgericht München HRB 6466
> > >> USt-IdNr: DE 129521671
> > >>
> > >
> >
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] MAGMA executable

[Vincent Carey]

I didn't find an obvious licensing statement at the magma site.  I did see

note that standard copyright applies; the MAGMA binaries and source code
may not be distributed or modified)

the licensing situation would affect my advice on this process, but others
may have other more
specific advice

On Thu, Dec 9, 2021 at 7:37 AM Brian Schilder <
brian_schil...@alumni.brown.edu> wrote:

> Hi everyone,
>
> I’m a developer for the R package MAGMA.Celltyping <
> https://github.com/neurogenomics/MAGMA_Celltyping/tree/bschilder_dev> (on
> the bschilder_dev branch). It’s currently only distributed via GitHub but
> I’m trying to get it on Bioc if possible. The dilemma is, it relies on
> MAGMA , which is only available as a
> CLI program.
>
> I have everything passing CRAN/Bioc checks on my local machine, but the
> final hurdle is installing MAGMA  on
> other machines (e.g. via GitHub Actions checks) such that it can be called
> from within R.
>
> Here’s the steps I’ve taken:
> Upon .onLoad <
> https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/zzz.R>
> of MAGMA.Celltyping, magma_installed_version() <
> https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/magma_installed_version.R>
> will check whether MAGMA is installed. If not, it proceeds to try and
> install it via magma_install() <
> https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/magma_install.R>
> .
> magma_install() finds the latest version of MAGMA in their archives <
> https://ctg.cncr.nl/software/MAGMA/prog/>, installs it wherever the user
> has permissions (from a list of possible installation locations <
> https://github.com/neurogenomics/MAGMA_Celltyping/blob/bschilder_dev/R/find_install_dir.R>),
> and sets up the symlink.
> Checks that MAGMA is indeed installed and callable from within R using
> functions like system(“magma ….”).
> This all seems to work fine locally, but when I launch to GitHub actions,
> MAGMA.Celltyping can’t seems to install/find MAGMA. it doesn’t seem to be
> able to find it.
>
> Does anyone know of any solutions to this that are Bioc (or at least CRAN)
> -compatible?
>
> Many thanks in advance,
> Brian
> ___
> Brian Schilder
> PhD Candidate
> UK Dementia Research Institute at Imperial College London
> Faculty of Medicine, Department of Brain Sciences, Neurogenomics Lab
> Profile | bit.ly/imperial_profile 
> LinkedIn | linkedin.com/in/brian-schilder <
> https://www.linkedin.com/in/brian-schilder/>
> Twitter | twitter.com/BMSchilder 
> Lab | neurogenomics.co.uk 
> UK DRI | www.ukdri.ac.uk 
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] [External] Memory error from sesame build

[Vincent Carey]

It seems noteworthy that this is occurring only for the i386 build on
windows.  i've had
no luck reproducing the error with

* sessionInfo()

R version 4.1.2 RC (2021-10-25 r81110)
Platform: i386-w64-mingw32/i386 (32-bit)
Running under: Windows 10 x64 (build 19043)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] sesame_1.12.5   sesameData_1.12.0   rmarkdown_2.11
[4] ExperimentHub_2.2.0 AnnotationHub_3.2.0 BiocFileCache_2.2.0
[7] dbplyr_2.1.1BiocGenerics_0.40.0

loaded via a namespace (and not attached):
 [1] bitops_1.0-7  matrixStats_0.61.0
 [3] bit64_4.0.5   filelock_1.0.2
 [5] RColorBrewer_1.1-2httr_1.4.2
 [7] GenomeInfoDb_1.30.0   tools_4.1.2
 [9] utf8_1.2.2R6_2.5.1
[11] KernSmooth_2.23-20DBI_1.1.1
[13] colorspace_2.0-2  withr_2.4.2
[15] DNAcopy_1.68.0tidyselect_1.1.1
[17] gridExtra_2.3 preprocessCore_1.56.0
[19] bit_4.0.4 curl_4.3.2
[21] compiler_4.1.2Biobase_2.54.0
[23] DelayedArray_0.20.0   scales_1.1.1
[25] randomForest_4.6-14   proxy_0.4-26
[27] rappdirs_0.3.3stringr_1.4.0
[29] digest_0.6.28 XVector_0.34.0
[31] pkgconfig_2.0.3   htmltools_0.5.2
[33] MatrixGenerics_1.6.0  fastmap_1.1.0
[35] rlang_0.4.12  RSQLite_2.2.8
[37] shiny_1.7.1   generics_0.1.1
[39] wheatmap_0.1.0BiocParallel_1.28.0
[41] dplyr_1.0.7   RCurl_1.98-1.5
[43] magrittr_2.0.1GenomeInfoDbData_1.2.7
[45] Matrix_1.3-4  Rcpp_1.0.7
[47] munsell_0.5.0 S4Vectors_0.32.0
[49] fansi_0.5.0   lifecycle_1.0.1
[51] stringi_1.7.5 yaml_2.2.1
[53] SummarizedExperiment_1.24.0   zlibbioc_1.40.0
[55] plyr_1.8.6grid_4.1.2
[57] blob_1.2.2parallel_4.1.2
[59] promises_1.2.0.1  ggrepel_0.9.1
[61] crayon_1.4.2  lattice_0.20-45
[63] Biostrings_2.62.0 KEGGREST_1.34.0
[65] knitr_1.36pillar_1.6.4
[67] fgsea_1.20.0  GenomicRanges_1.46.0
[69] reshape2_1.4.4stats4_4.1.2
[71] fastmatch_1.1-3   glue_1.4.2
[73] BiocVersion_3.14.0evaluate_0.14
[75] data.table_1.14.2 BiocManager_1.30.16
[77] png_0.1-7 vctrs_0.3.8
[79] httpuv_1.6.3  gtable_0.3.0
[81] purrr_0.3.4   assertthat_0.2.1
[83] cachem_1.0.6  ggplot2_3.3.5
[85] xfun_0.27 mime_0.12
[87] xtable_1.8-4  e1071_1.7-9
[89] later_1.3.0   class_7.3-19
[91] tibble_3.1.5  AnnotationDbi_1.56.2
[93] memoise_2.0.1 IRanges_2.28.0
[95] ellipsis_0.3.2interactiveDisplayBase_1.32.0


or with

 sessionInfo()
R version 4.1.2 RC (2021-10-25 r81110)
Platform: i386-w64-mingw32/i386 (32-bit)
Running under: Windows 10 x64 (build 19043)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] sesame_1.12.5   sesameData_1.12.0   rmarkdown_2.11
[4] ExperimentHub_2.2.0 AnnotationHub_3.2.0 BiocFileCache_2.2.0
[7] dbplyr_2.1.1BiocGenerics_0.40.0

loaded via a namespace (and not attached):
 [1] bitops_1.0-7  matrixStats_0.61.0
 [3] bit64_4.0.5   filelock_1.0.2
 [5] RColorBrewer_1.1-2httr_1.4.2
 [7] GenomeInfoDb_1.30.0   tools_4.1.2
 [9] utf8_1.2.2R6_2.5.1
[11] KernSmooth_2.23-20DBI_1.1.1
[13] colorspace_2.0-2  withr_2.4.2
[15] DNAcopy_1.68.0tidyselect_1.1.1
[17] gridExtra_2.3 preprocessCore_1.56.0
[19] bit_4.0.4 curl_4.3.2
[21] compiler_4.1.2Biobase_2.54.0
[23] DelayedArray_0.20.0   scales_1.1.1
[25] randomForest_4.6-14   proxy_0.4-26
[27] rappdirs_0.3.3stringr_1.4.0
[29] digest_0.6.28 XVector_0.34.0
[31] pkgconfig_2.0.3   htmltools_0.5.2
[33] MatrixGenerics_1.6.0  fastmap_1.1.0
[35] rlang_0.4.12  RSQLite_2.2.8
[37] shiny_1.7.1   generics_0.1.1
[39] wheatmap_0.1.0BiocParallel_1.28.2
[41] dplyr_1.0.7   RCurl_1.98-1.5
[43] magrittr_2.0.1

Re: [Bioc-devel] JAVA_HOME cannot be determined on Windows on Bioconductor platform report

[Vincent Carey]

I found
```

Error in `toSBGN(system.file("extdata",
"biopax3-short-metabolic-pathway.owl",
package = "paxtoolsr"), outFile)`: java.lang.UnsatisfiedLinkError:
C:\Program Files\Java\jre1.8.0_311\bin\awt.dll: Can't find dependent
libraries

[ FAIL 1 | WARN 1 | SKIP 3 | PASS 58 ]
```
on a pretty stock windows install on azure.

Now it is a little bleeding edge, but maybe you could  comment on this
error?


R Under development (unstable) (2021-10-19 r81074 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19043)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United
States.utf8LC_MONETARY=English_United States.utf8
[4] LC_NUMERIC=C   LC_TIME=English_United
States.utf8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] rcmdcheck_1.4.0

loaded via a namespace (and not attached):
 [1] ps_1.6.0 prettyunits_1.1.1digest_0.6.28
 crayon_1.4.1 withr_2.4.2
 [6] rprojroot_2.0.2  R6_2.5.1 cli_3.0.1
 curl_4.3.2   callr_3.7.0
[11] desc_1.4.0   tools_4.2.0  compiler_4.2.0
processx_3.5.2   pkgbuild_1.2.0
[16] xopen_1.0.0  BiocManager_1.30.16.1001


On Fri, Oct 22, 2021 at 12:25 PM Augustin Luna  wrote:

> Thanks for the responses. But they are not addressing my problem. I
> have GitHub Actions checking the package on Windows/macOS/Linux using
> Java OpenJDK 14 with tests/examples running fine on both R release and
> devel.
>
> https://github.com/BioPAX/paxtoolsr/actions/runs/1372348962
>
> At this point, I'm not debugging my code rather the Bioconductor build
> system. Tests/examples that do not run on Bioconductor are running
> fine elsewhere.
>
> More helpful to me would be instructions to some VM file or Docker
> container where I could mimic the Bioconductor setup. I'm at a loss
> for how to debug this problem or what is unique about the Bioconductor
> system.
>
> Searching through code from other packages is not helpful unless I
> know what I'm looking for. In this case, it means a package that had a
> "JLRequestRuntimeInstall: Error calling: CFMessagePortCreateRemote"
> error and addressed it successfully.
>
> Stack Overflow only gives me hints regarding
> "CFMessagePortCreateRemote" errors in that there is a problem with the
> installation of Java:
>
>
> https://stackoverflow.com/questions/15289059/install-java-on-mac-osx-10-8-2-error-calling-cfmessageportcreateremote
>
> PS: I removed the "which java" call.
>
> Thanks,
> Augustin Luna
>
> On Mon, Oct 18, 2021 at 3:14 PM Hervé Pagès 
> wrote:
> >
> > Hi Augustin,
> >
> > Please don't rely on JAVA_HOME to detect Java. The JDK installer on
> > Windows doesn't set this variable so you shouldn't expect it to be set
> > on the user's machine. AFAIK the other Bioconductor packages that depend
> > on Java don't use their own code to detect Java. Instead I believe that
> > they run their Java code via rJava so they delegate to rJava the
> > responsibility to find Java for them.
> >
> > Here is the list of all Bioconductor packages that depend on rJava:
> >
> >ArrayExpressHTS
> >(not supported on Windows)
> >BridgeDbR
> >
> >CHRONOS
> >
> >    debCAM
> >
> >esATAC
> >
> >gaggle
> >
> >Onassis
> >
> >ReQON
> >
> >RGMQL
> >
> >rmelting
> >
> >sarks
> >
> >SELEX
> >
> >
> > Feel free to take a look at how they handle this.
> >
> > Cheers,
> > H.
> >
> >
> > On 18/10/2021 10:13, Vincent Carey wrote:
> > > That should be fixable.  The build system needs to have a correct
> setting
> > > for JAVA_HOME.  But you have
> > > clearly nonportable code in .onLoad in paxtoolsr.R -- system("which
> java")
> > > ... this should not be
> > > necessary at all, just import rJava.
> > >
> > > On Mon, Oct 18, 2021 at 12:29 PM Augustin Luna 
> wrote:
> > >
> > >> I have the following error:
> > >>
> > >> "error: JAVA_HOME cannot be determined from the Registry"
> > >>
> > >> for this package:
> > >>
> > >>
> > >>
> https://bioconductor.org/checkResults/devel/bioc-LATEST/paxtoolsr/riesling1-install.html
> > >>
> > >> I have been given assurances that Java is present but given this
> > >> error, I am not so sure and I am unsure how to debug or fix it.
> > >>
> > >> Can anyone suggest how to proceed?
> > >>
> > >> Thanks,
> > >> Augustin Luna
> > >>
> > >> ___
> > >> Bioc-devel@r-project.org mailing list
> > >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > >>
> > >
> >
> > --
> > Hervé Pagès
> >
> > Bioconductor Core Team
> > hpages.on.git...@gmail.com
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] JAVA_HOME cannot be determined on Windows on Bioconductor platform report

[Vincent Carey]

That should be fixable.  The build system needs to have a correct setting
for JAVA_HOME.  But you have
clearly nonportable code in .onLoad in paxtoolsr.R -- system("which java")
... this should not be
necessary at all, just import rJava.

On Mon, Oct 18, 2021 at 12:29 PM Augustin Luna  wrote:

> I have the following error:
>
> "error: JAVA_HOME cannot be determined from the Registry"
>
> for this package:
>
>
> https://bioconductor.org/checkResults/devel/bioc-LATEST/paxtoolsr/riesling1-install.html
>
> I have been given assurances that Java is present but given this
> error, I am not so sure and I am unsure how to debug or fix it.
>
> Can anyone suggest how to proceed?
>
> Thanks,
> Augustin Luna
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Best Practices for Renaming S4 Slots

[Vincent Carey]

I find your arguments fairly reasonable.  I wonder if you have been through
the process of restoring
data from an object serialized with the old slot names, using the revised
package.  Maybe it is not even a use case for your
packages.  If you have worked through the implications of this change for
all dependent packages,
and since the policy on slot names is not clearly articulated, I would be
inclined to allow the change -- but I would like
to hear from other folks on bioc-devel and in our core.

On Fri, Oct 15, 2021 at 1:51 PM Chris Eeles 
wrote:

> Hi Vincent,
>
> Thanks for sharing your thoughts.
>
>
>
> I guess my thinking was that the entire point of using S4 classes and OOP
> is having accessor methods to provide an implementation independent API. In
> the Bioconductor guidelines it specifically tells users not to access slots
> using the `@` operator, as an implementation change in the class may break
> any scripts doing so. Therefore, my changing slot names should have no
> effect on users following the Bioconductor coding best practices, assuming
> I maintain the old accessors methods with a .Deprecation warning, as per
> the cited guideline. That was indeed my plan.
>
> So I would argue that no, class definitions are not part of the API,
> especially if I am just renaming slots. Indeed isn’t that one of the
> supposed strengths of OOP programming and the use of interfaces?
>
> Obviously I have already agreed to wait for 3.15 to make the changes, but
> I do not think it is clear from the current guidelines that deprecation
> rules apply to slots. Given that `@` isn’t even a generic, there would be
> no way to send a message to the user except through the accessor methods,
> which they would never see if they weren’t already using the accessor API.
> So for users accessing data via `@`, the deprecation guidelines provide no
> benefits because they failed to follow the best practices.
>
> My opinion of the developer-user contract for S4 classes is that the API
> would not change without due warning, and if implementation really is
> independent of interface, then any changes made to an S4 class should be
> fine, so long as all the original methods still work and can be deprecated
> according to the cited guidelines.
>
> Additionally, if changes to a class require so much work, it incentives
> developers to simply ditch old S4 classes and reimplement them in a new
> package. Doesn’t that go against the spirit of reuse that is supposed to be
> encouraged by adoption of S4 classes?
>
> TL;DR – IMO API = interface; implementation is developer business
>
> Best,
>
> Chris
>
>
>
> *From:* Vincent Carey 
> *Sent:* October 15, 2021 1:31 PM
> *To:* Chris Eeles 
> *Cc:* Hervé Pagès ; bioc-devel@r-project.org
> *Subject:* Re: [Bioc-devel] Best Practices for Renaming S4 Slots
>
>
>
> I will defer to Herve about all details, but I would say that this level
> of change control is implied by the "no changes
>
> to package API without an interval of deprecation spanning at least one
> release".  See https://bioconductor.org/developers/how-to/deprecation/
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbioconductor.org%2Fdevelopers%2Fhow-to%2Fdeprecation%2F=04%7C01%7C%7C8ec56a4ffda74802e7ab08d990019bc7%7C84df9e7fe9f640afb435%7C1%7C0%7C637699158846578705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=1vILqDKSUJPMJ5gKZ1y%2Ftlf8rKtrZmX6tL6xGTINEo8%3D=0>
>
> That text mentions that removal may take 18 months.
>
>
>
> Whatever is exposed cannot be changed without a deprecation period,
>
> in which the functionality is preserved, but notification is given to
> users/developers, through .Deprecated, that
>
> functionality will change and advice is given on the alternate approach to
> be used.
>
>
>
> Is a slot name part of the API?  It isn't completely obvious, but in the
> case of serialized objects, it turns out that it is.
>
> I don't know that our guidelines have sufficient details on this process,
> but we welcome your input on where to
>
> best outline/advertise this.
>
>
>
> On Fri, Oct 15, 2021 at 1:22 PM Chris Eeles 
> wrote:
>
> Message received. I will leave that branch for later. Is this information
> available on the Bioconductor website at all? It would have been useful to
> find out sooner.
>
> Best,
> Chris
>
> -Original Message-
> From: Bioc-devel  On Behalf Of Chris
> Eeles
> Sent: October 15, 2021 1:10 PM
> To: Hervé Pagès ; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Best Practices for Renaming S4 Slots
>
> Thanks Herve,
>
> I actually got the updateObject method working after

Re: [Bioc-devel] Best Practices for Renaming S4 Slots

[Vincent Carey]

I will defer to Herve about all details, but I would say that this level of
change control is implied by the "no changes
to package API without an interval of deprecation spanning at least one
release".  See https://bioconductor.org/developers/how-to/deprecation/
That text mentions that removal may take 18 months.

Whatever is exposed cannot be changed without a deprecation period,
in which the functionality is preserved, but notification is given to
users/developers, through .Deprecated, that
functionality will change and advice is given on the alternate approach to
be used.

Is a slot name part of the API?  It isn't completely obvious, but in the
case of serialized objects, it turns out that it is.
I don't know that our guidelines have sufficient details on this process,
but we welcome your input on where to
best outline/advertise this.

On Fri, Oct 15, 2021 at 1:22 PM Chris Eeles 
wrote:

> Message received. I will leave that branch for later. Is this information
> available on the Bioconductor website at all? It would have been useful to
> find out sooner.
>
> Best,
> Chris
>
> -Original Message-
> From: Bioc-devel  On Behalf Of Chris
> Eeles
> Sent: October 15, 2021 1:10 PM
> To: Hervé Pagès ; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Best Practices for Renaming S4 Slots
>
> Thanks Herve,
>
> I actually got the updateObject method working after sending this email,
> but thanks for the information. Maybe it is worth adding a section on this
> topic to the Bioconductor developer section?
>
> Unfortunately, I was unaware that the start of development cycle was the
> best time to implement this change. I am currently planning to have this
> done for the 3.14 release.
>
> I am introducing new accessors as well but keeping the old ones for
> backwards compatibility using aliases.
>
> How discouraged are slot name changes in a release? A lot of the changes
> on our road map require the slots to be renamed so it would significantly
> delay required features if I were to wait.
>
> I plan to put in the work so that those using accessors shouldn't notice a
> difference.
>
> Best,
> Chris
>
> -Original Message-
> From: Hervé Pagès 
> Sent: October 15, 2021 12:39 PM
> To: Chris Eeles ; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] Best Practices for Renaming S4 Slots
>
> Hi Chris,
>
> There was some formatting issues with my previous answer so I'm sending it
> again. Hopefully this time the formatting is better. See below.
>
> On 14/10/2021 13:08, Chris Eeles wrote:
> > Hello BioC community,
> >
> > I am the lead developer for the CoreGx, PharmacoGx, RadioGx and ToxicoGx
> packages. We have recently been working on major updates to the structure
> of a CoreSet, which is inherited by the main class in all three of the
> other packages listed.
> >
> > While making these changes, we would like to rename some CoreSet slots
> to increase the amount of code that can be refactored into CoreGx,
> simplifying maintenance and development of inheriting packages in the
> future.
> >
> > The slot names and their accessors will be made more generic, for
> example the 'cell' slot will become 'sample' to allow a CoreSet derived
> class to store Biological model systems other than cancer cell lines.
> Similarly, 'drug' or 'radiation' slots in inheriting packages will be
> replaced with a 'treatment' slot in the CoreSet. This will allow us to
> simplify inheritance, removing much redundant code from the inheriting
> packages and setting us up to integrate other lab packages, such as Xeva
> for PDX models, into the general CoreSet infrastructure.
> >
> > I took a brief look through the Bioconductor developer documentation but
> didn't see anything talking about best practices for renaming slots.
> >
> > It is easy enough to make the code changes, but my major concern is
> being able to update existing objects from these packages to use the new
> slot names.
> >
> > I am aware of the updateObject function in BiocGenerics, but tried using
> it to update some example data in CoreGx without success.
> >
> > Is this the proper function to use when you wish to update an S4 object
> whose class definition has been modified? If not, is there existing
> infrastructure for accomplishing this task?
>
> Yes updateObject() is the proper function to use but the function has no
> way to guess how to fix your objects. The way you tell it what to do is by
> implementing methods for your objects.
>
> For example if you renamed the 'cell' slot -> 'sample', your
> updateObject() method will be something like this:
>
>
> setMethod("updateObject", "CoreSet",
>  function(object, ..., verbose=FALSE)
>  {
>  ## The "cell" slot was renamed -> "sample" in CoreGx_1.7.1.
>  if (.hasSlot(object, "cell")) {
>  object <- new("CoreSet",
>sensitivity=object@sensitivity,
>annotation=object@annotation,
>

[Bioc-devel] Recent contribution processing

[Vincent Carey]

Contribution processing has encountered some technical difficulties.
We expect normal operations to resume Monday.  Contributors of
new packages should hold steady; moderation and review will
resume ASAP.

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Issues with package size

[Vincent Carey]

It seems to me the reason for the large vignette size is that you have
significant DT::datatable rendering
capabilities within your vignettes, and the tables are large.  I would
propose that you use subsets of the
table content for the vignettes, and direct the reader who wants to search
the entire table interactively, to
run a function in the package that will produce the full table in datatable
format.


On Thu, Sep 23, 2021 at 8:56 AM Giulia Pais  wrote:

> Hi Lori,
> It is mainly data and a couple of plots, no images. Even if there is very
> minimal data somehow we can’t obtain vignettes smaller than 1 MB.
>
>
> From: "Kern, Lori" 
> Date: Thursday, September 23, 2021 at 14:52
> To: Zuguang Gu , Giulia Pais 
> Cc: "bioc-devel@r-project.org" 
> Subject: Re: [Bioc-devel] Issues with package size
>
> In generally, Bioconductor will always require at least one vignette
> automatically checked and that performs non trivial calls to package code.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of Zuguang
> Gu 
> Sent: Thursday, September 23, 2021 8:45 AM
> To: Giulia Pais 
> Cc: bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] Issues with package size
>
> Hi Giulia,
>
> I think it is ok to host the vignettes somewhere else. I have two packages
> of which the vignettes are hosted on GitHub Page.
>
> http://www.bioconductor.org/packages/devel/bioc/html/ComplexHeatmap.html
> https://www.bioconductor.org/packages/devel/bioc/html/cola.html
>
> But since now the vignettes are not automatically checked, you need to make
> sure every time you update your package, the vignettes can be successfully
> generated.
>
> Cheers,
> Zuguang
>
>
> On Thu, 23 Sept 2021 at 14:07, Giulia Pais  wrote:
>
> > Hello, I’m the developer of the package ISAnalytics.
> > I’d like to ask if it is possible to have a file/vignette that links to
> > other documentation outside the package (like a GitHub wiki) since we
> have
> > issues with the maximum allowed package size due to vignette size, We
> would
> > like to maintain as much documentation as possible and we already tried
> to
> > reduce data included but it’s not sufficient.
> > Thanks in advance
> > Giulia Pais
> >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> >
> https://secure-web.cisco.com/1bVwVH2TSjLktt0qOqzdmtPQeyStFct50lyqYggqz0cWVZz5Nrl13NmfUZgC3uXfgqj0OAIUk0NpuvXaN4Sl8Y4RUv0VLrJI3zmz8Slm6fsVr-gGcVOy_bZL-9KWc0IqbhzJi4vfa7naMQ8TWtKOAnzqR6BWM0zUrhPVfh59QSaBIcwcztT6-chMXAfU01xkg057qask_cA8EduifzdqUaqRELZKrVd1l8wwioW7U8s8pa_FMzA6tEE5A_Ddl62UCFeMvxnXuQjkyvm1Yuh2hgZ9HDGeZOKg_ZgpmZXyI2OVInjnXlv4sCexb93Tkd5Ox/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1bVwVH2TSjLktt0qOqzdmtPQeyStFct50lyqYggqz0cWVZz5Nrl13NmfUZgC3uXfgqj0OAIUk0NpuvXaN4Sl8Y4RUv0VLrJI3zmz8Slm6fsVr-gGcVOy_bZL-9KWc0IqbhzJi4vfa7naMQ8TWtKOAnzqR6BWM0zUrhPVfh59QSaBIcwcztT6-chMXAfU01xkg057qask_cA8EduifzdqUaqRELZKrVd1l8wwioW7U8s8pa_FMzA6tEE5A_Ddl62UCFeMvxnXuQjkyvm1Yuh2hgZ9HDGeZOKg_ZgpmZXyI2OVInjnXlv4sCexb93Tkd5Ox/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
> This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] BrowserViz build test times out, checks for web browser availability, apparently needs update

[Vincent Carey]

Sorry for delay in responding Paul.  I had a look at BrowserViz and ran into

> PORT_RANGE <- 12111:12120
> if(BrowserViz::webBrowserAvailableForTesting()){
+bvApp <- BrowserViz(browserFile=browserVizBrowserFile, quiet=TRUE)
+data <- list(lowercase=letters, uppercase=LETTERS)
+json.returned <- roundTripTest(bvApp, data)
+data.returned <- fromJSON(json.returned)
+message(sprintf("%5d bytes exchanged", nchar(json.returned)))
+stopifnot(data == data.returned)
+html <- sprintf("round trip of json-encoded data, %d chars",
+nchar(json.returned))
+displayHTMLInDiv(bvApp, html, "bvDemoDiv")
+}
attempting to open websocket connection on port 1
BrowserViz websocket ready after   1.30 seconds
  237 bytes exchanged
Error in data == data.returned :
  comparison of these types is not implemented

Maybe we can discuss this on issues in BrowserViz github ... where is
that?  Then
we can bring back the solution to bioc-devel.

On Wed, Dec 30, 2020 at 1:25 PM Paul Shannon <
paul.thurmond.shan...@gmail.com> wrote:

> The BrowserViz package - currently timing out on malbec1 and nebbiolo1,
> supports json messaging over websockets between R and most web browsers.
>
> The unit tests for BrowserViz only run if a web browser is available.   In
> recent years, a (presumably headless) web browser was offered on the Linux
> build machines. Depending on that, and for a few years, the following
> conditional execution has worked.  But maybe no longer?
>
> webBrowserAvailableForTesting <- function() {
>   authorsDevelopmentMachine <- grepl("hagfish", Sys.info()["nodename"])
>   bioconductorBuildSystem.linux <- with(as.list(Sys.info()), sysname ==
> "Linux")
>   interactiveUse <- interactive()
>   return(authorsDevelopmentMachine || bioconductorBuildSystem.linux ||
> interactiveUse)
>   }
>
> Any suggestions?
>
> Thank you,
>
>  - Paul
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Changing package names

[Vincent Carey]

Please reconsider.  The names of your packages enter components of a
metadata collection
that must be manually altered by our core development staff to accommodate
package name changes.
While it is easy to change names of entities in programs and local file
systems, our package
ingestion, review, compilation, verification, and distribution system is
delivering resources to
thousands of users around the world every day.  We do not have the capacity
to make changes
of this kind for any but the most severe errors of name selection, for
example, employing a name
that is legally forbidden.  If this is in fact the case, you will have to
withdraw the package, have
it deprecated, and resubmit under another name.  We cannot promise rapid
turnaround for this
process.

Thank you

On Tue, Aug 17, 2021 at 10:40 AM Kramer, Nicole Emma 
wrote:

> Hello all,
>
> My submitted package BentoBox and its associated data package BentoBoxData
> have been accepted and were just added to Bioconductor's git repository.
> Unfortunately, my group and I would like to change the names of these
> packages/repositories. What would be the appropriate process to change the
> names of these packages if they are already in Bioconductor's git
> repository?
>
> Thank you,
> Nicole Kramer
>
>
>
> Nicole Kramer
>
> Ph.D. Student in Bioinformatics and Computational Biology
>
> University of North Carolina at Chapel Hill
>
> nekra...@live.unc.edu
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Large data frames in inst/extdata

[Vincent Carey]

If the data frames are outcomes of experiments (wet lab or computational)
use ExperimentHub

If annotation, use AnnotationHub

Submission instructions for these Hub contributions are available at, e.g.,
https://bioconductor.org/packages/release/bioc/vignettes/ExperimentHubData/inst/doc/ExperimentHubData.html


On Wed, Aug 4, 2021 at 3:32 PM Kelsey Chetnik via Bioc-devel <
bioc-devel@r-project.org> wrote:

> I have a package I would like to submit to Bioconductor. Some functions of
> the package utilize precalculated data frames currently stored in the
> inst/extdata directory. These data frames result in the source package
> exceeding 5 MB (~25 MB).
>
> Are there any best practices or recommendations for storing data frames
> that are required for certain functions?
>
> Thanks,
> Kelsey
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Could anyone help me to fix it?

[Vincent Carey]

see entry 16 here https://bioconductor.org/developers/how-to/git/faq/

On Wed, Jul 28, 2021 at 6:32 AM Guo Kai  wrote:

> Hi,
> I git an error:
> Load key "/Users/bioguo/.ssh/id_rsa.pub": bad permissions
> g...@git.bioconductor.org : Permission
> denied (publickey).
> fatal: Could not read from remote repository.
> Thanks!
> Kai
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] pre-receive hook declined

[Vincent Carey]

hi you can't update 3.12  3.x is frozen when 3.(x+1) becomes release
perhaps the error message can be clarified

On Tue, Jul 27, 2021 at 3:44 PM Clay Wright  wrote:

> Hi,
>
> I am now encountering the following similar error trying to push a bugfix
> to my package. Does my account also need a similar update to Victor and
> Mike? Or is this something on my end? I just finally updated my github
> personal access tokens, maybe that's the issue? I haven't tried a fresh
> clone of the repository yet.
>
>
> git push origin RELEASE_3_12
>
> Enumerating objects: 17, done.
> Counting objects: 100% (17/17), done.
> Delta compression using up to 4 threads
> Compressing objects: 100% (12/12), done.
> Writing objects: 100% (12/12), 1.48 KiB | 151.00 KiB/s, done.
> Total 12 (delta 9), reused 0 (delta 0), pack-reused 0
> remote: FATAL: W refs/heads/RELEASE_3_12 packages/flowTime r.wright DENIED
> by fallthru
> remote: error: hook declined to update refs/heads/RELEASE_3_12
> To git.bioconductor.org:packages/flowTime.git
>  ! [remote rejected] RELEASE_3_12 -> RELEASE_3_12 (hook declined)
> error: failed to push some refs to 'git.bioconductor.org:
> packages/flowTime.git'
>
>
> Thanks!
> Clay
>
>
> On Fri, Jul 2, 2021 at 1:30 PM Victor Yuan  wrote:
>
> > It works for me as well now. Thanks!
> >
> > On Thu, Jul 1, 2021 at 8:21 AM Michael Love  >
> > wrote:
> >
> > > That works for me. Thanks.
> > >
> > > Mike
> > >
> > > On Thu, Jul 1, 2021 at 2:07 PM Nitesh Turaga 
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > Please try again. You should not see this error anymore.
> > > >
> > > > This was a mistake on our end.
> > > >
> > > > Best,
> > > >
> > > > Nitesh
> > > >
> > > >
> > > >
> > > > Nitesh Turaga
> > > > Scientist II, Department of Data Science,
> > > > Bioconductor Core Team Member
> > > > Dana Farber Cancer Institute
> > > >
> > > > > On Jul 1, 2021, at 1:49 AM, Michael Love <
> > michaelisaiahl...@gmail.com>
> > > wrote:
> > > > >
> > > > > I'm getting a similar error, trying to push commits for a new
> package
> > > > > submission. So this is my first attempt to push to Bioc git servers
> > > > > for this package.
> > > > >
> > > > > After following instructions from
> > > > >
> https://bioconductor.org/developers/how-to/git/new-package-workflow/
> > > > > ...
> > > > >
> > > > > spatialDmelxsim git:(main) > git push upstream main:master
> > > > > Enumerating objects: 20, done.
> > > > > Counting objects: 100% (20/20), done.
> > > > > Delta compression using up to 8 threads
> > > > > Compressing objects: 100% (10/10), done.
> > > > > Writing objects: 100% (12/12), 1.60 KiB | 1.60 MiB/s, done.
> > > > > Total 12 (delta 5), reused 0 (delta 0), pack-reused 0
> > > > > remote: Traceback (most recent call last):
> > > > > remote:   File
> > > "hooks/pre-receive.h00-pre-receive-hook-dataexp-workflow",
> > > > > line 90, in 
> > > > > remote: apply_hooks(hooks_dict)
> > > > > remote:   File
> > > "hooks/pre-receive.h00-pre-receive-hook-dataexp-workflow",
> > > > > line 72, in apply_hooks
> > > > > remote: if hooks_dict["pre-receive-hook-merge-markers"]:  #
> > enable
> > > hook
> > > > > remote: KeyError: 'pre-receive-hook-merge-markers'
> > > > > To git.bioconductor.org:packages/spatialDmelxsim
> > > > > ! [remote rejected] main -> master (pre-receive hook declined)
> > > > > error: failed to push some refs to
> > > > > 'git.bioconductor.org:packages/spatialDmelxsim'
> > > >
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] MOFA2 build error

[Vincent Carey]

It's good that it works on the other platforms.  We will look at this
failure closely.

On Mon, Jul 26, 2021 at 2:35 AM Britta Velten 
wrote:

> Dear all,
>
> We are currently experiencing a build error in the dev version of MOFA2 on
> merida1.
>
> http://bioconductor.org/checkResults/devel/bioc-LATEST/MOFA2/merida1-buildsrc.html
> <
> http://bioconductor.org/checkResults/devel/bioc-LATEST/MOFA2/merida1-buildsrc.html
> >
>
> I am not able to reproduce this error, it seems to be related to a call to
> python via reticulate.
> The conda environment for this is set up using basilisk. When connecting
> to python in a vignette the build stops with
> sh: line 1: 69703 Abort trap: 6
>  
> '/Users/biocbuild/Library/Caches/org.R-project.R/R/basilisk/1.5.0/MOFA2/1.3.3/mofa_env/bin/python'
> '/Library/Frameworks/R.framework/Versions/4.1/Resources/library/reticulate/config/config.py'
> 2> /dev/null
> one node produced an error: Error 134 occurred running
> /Users/biocbuild/Library/Caches/org.R-project.R/R/basilisk/1.5.0/MOFA2/1.3.3/mofa_env/bin/python
>
> Do you have any ideas what is going wrong here and suggestions how to fix
> this?
> The build seems to work fine on all other platforms.
>
> Thanks and all the best,
> Britta
>
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Getting ready for package submission, running into a couple of errors/warnings that I can't figure out

[Vincent Carey]

On Mon, Jul 12, 2021 at 5:58 PM Wight, Andrew E. <
andrewe_wi...@dfci.harvard.edu> wrote:

> Good evening all - I'm getting my first package ready for submission to
> Bioconductor, and I'm running into a couple of errors/warnings when I run R
> CMD CHECK or BiocCheck. All of my current troubleshooting on these errors
> has come up blank, so I'm hoping someone here can point me in the right
> direction.
>
> I'm running R4.1 on Ubuntu 20.04, Bioconductor 3.13, and BiocCheck 1.28
>

Hi, you should be using Bioconductor 3.14 to develop a new contribution at
this time -- see http://contributions.bioconductor.org/general.html


>
>
>   1.  R CMD check warning: ‘qpdf’ is needed for checks on size reduction
> of PDFs
>
> I am getting this warning with R CMD check despite the fact that I have
> installed qpdf and it is visible to my R session. Stack Exchange suggested
> a couple of fixes in .Renviron, none of which helped. This seems like a new
> problem in R4.x, and possibly is only a problem with packages intended for
> CRAN, but I wanted to make sure it wouldn't cause headaches during review.
>

see 1.6.1 of https://cran.r-project.org/doc/manuals/R-exts.html

You may be able to diagnose your problem (which may involve the way in
which R was built for your linux system)
by building with --compact-vignettes

This condition should not stop you from submitting.


>
>
>   1.  BiocCheck error: Maintainer must register at the support site; visit
> https://support.bioconductor.org/accounts/signup/
>
> I am registered on the support site as andrewe_wi...@dfci.harvard.edu,
> which is the same email address as listed in my package's DESCRIPTION, so
> I'm not sure what else to do here. I've been registered on the support site
> for 7 months now and have a verified email address.
>
>
Just proceed


>
>   1.  BiocCheckGitClone error: System Files found that should not be git
> tracked:
> flowGate.Rproj
> .Rhistory
>
> I accidentally tracked these two files ages past, but have long since
> added them to .gitignore and deleted them with git rm --cached .
> I can confirm that they are gone with git ls-files and git ls-files
> --cache; they appear in neither of these lists when I run the command. To
> be certain, I made a fresh clone of the repo on a new computer and ran
> BiocCheckGitClone, but still got this error despite neither of these files
> showing up anywhere in the git as far as I can tell.
>
>
Did you provide the repo name, perhaps I can check too.  I see that Nitesh
has given additional advice.

Once you have minimized R CMD and BiocCheck checking warnings, submit the
package.  The Single Package
Builder and review process will be informative about mandatory
modifications.  We are working to help developers
have the ability to fully emulate our build/check processes but are not
there yet.


> My apologies for what seem like basic problems - these look like they
> should be straightforward fixes (install qpdf, register for the site, and
> remove the offending files), but none of those fixes worked and I'm not
> sure where to go from here. Any insight anyone can give on how to fix these
> errors is greatly appreciated!
>
> Thanks,
>
> -Andrew
>
>
>
>
> The information in this e-mail is intended only for th...{{dropped:26}}

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

Re: [Bioc-devel] Package did not update after push

[Vincent Carey]

Your changes are present in Bioconductor git.  The next available build
report should
reflect their effects.

On Mon, Jul 5, 2021 at 7:49 AM Fabricio de Almeida <
fabricio_almeidasi...@hotmail.com> wrote:

> Hi, all.
>
> I pushed a simple bug fix to my package BioNERO on Friday, but the Bioc
> page still shows "Updated before release" (see
> https://bioconductor.org/packages/release/bioc/html/BioNERO.html). I know
> it can take up to 48 hours for the changes to be visible, but I pushed more
> than 48 hours ago. Does anyone know what may have happened?
>
> Useful info:
> This is the output of some git commands in my local machine, in my package
> directory:
>
> $ git branch -a
>
> * RELEASE_3_13
>
>   master
>
>   remotes/origin/RELEASE_3_13
>
>   remotes/origin/master
>
>   remotes/upstream/RELEASE_3_13
>
>   remotes/upstream/master
>
> $ git status
>
> On branch RELEASE_3_13
>
> Your branch is up to date with 'upstream/RELEASE_3_13'.
>
>
> nothing to commit, working tree clean
>
>
>
> In the GitHub repo for this package, everything is fine:
> https://github.com/almeidasilvaf/BioNERO/tree/RELEASE_3_13
> When I made the changes, I bumped the RELEASE_3_13 version from 1.0.0 to
> 1.0.1 and the devel (master) version from 1.1.0 to 1.1.1.
>
> Best,
>
>
> =
>
>
> Fabrício de Almeida Silva
>
> Undergraduate degree in Biological Sciences (UENF)
>
> MSc. candidate in Plant Biotechnology (PGBV/UENF - RJ/Brazil)
>
> Laboratório de Química e Função de Proteínas e Peptídeos (LQFPP/CBB/UENF -
> RJ/Brazil)
>
> Lattes CNPq: http://lattes.cnpq.br/3119358824056108
>
> Personal website: https://almeidasilvaf.github.io/home/
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Build error

[Vincent Carey]

Thanks for your note.  I had a look at your vignette and found

devtools::install_github('christophergandrud/repmis')

That's not permitted.  repmis is on CRAN and seems synced with the github
repo,
so please take this out.

You also have a download event in the vignette.

> source_data("
https://github.com/GenomicsPrograms/example_data/raw/master/PoTRA-vignette.RData
")
Downloading data from:
https://github.com/GenomicsPrograms/example_data/raw/master/PoTRA-vignette.RData


If the data do not fit in your package, please arrange to place them in the
appropriate Hub.

Finally

> humanBiocarta <- pathways("hsapiens", "biocarta")
Error: no database "biocarta" for species "hsapiens"

graphite doesn't support biocarta any more, it seems.

On Sat, Jul 3, 2021 at 8:49 AM margaret linan  wrote:

> Hi -
>
> The PoTRA package has not experienced build errors for the majority of the
> last two years until recently. Can you clarify if these build errors are
> due to bioconductor environmental failure or hardware failure? If not, can
> you help me understand the build error root cause so that I can resolve
> this error?
>
> Thanks.
> ML
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] pre-receive hook declined

[Vincent Carey]

are you using wvictor14

On Wed, Jun 30, 2021 at 1:41 PM Victor Yuan  wrote:

> Hi I cannot seem to push to the remote g...@git.bioconductor.org:
> packages/GSE159526
>
> I get a "pre-receive hook declined" error:
>
> 
> $ git push upstream master
> Enumerating objects: 21, done.
> Counting objects: 100% (21/21), done.
> Delta compression using up to 12 threads
> Compressing objects: 100% (15/15), done.
> Writing objects: 100% (15/15), 1.55 KiB | 1.55 MiB/s, done.
> Total 15 (delta 9), reused 0 (delta 0), pack-reused 0
> remote: Traceback (most recent call last):
> remote:   File "hooks/pre-receive.h00-pre-receive-hook-dataexp-workflow",
> line 89, in 
> remote: apply_hooks(hooks_dict)
> remote:   File "hooks/pre-receive.h00-pre-receive-hook-dataexp-workflow",
> line 71, in apply_hooks
> remote: if hooks_dict["pre-receive-hook-merge-markers"]:  # enable hook
> remote: KeyError: 'pre-receive-hook-merge-markers'
> To git.bioconductor.org:packages/GSE159526
>  ! [remote rejected] master -> master (pre-receive hook declined)
> error: failed to push some refs to 'git.bioconductor.org:
> packages/GSE159526'
> 
>
> I checked, and my ssh keys are configured correctly.
>
> https://github.com/Bioconductor/Contributions/issues/2170
>
> Any help appreciated!
> Victor
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Build report page is not updated, DOI leads nowhere

[Vincent Carey]

On Sat, Jun 26, 2021 at 6:18 PM Oleksii Nikolaienko <
oleksii.nikolaie...@gmail.com> wrote:

> Dear Bioc team,
> I recently pushed changes to the release branch and was waiting for
> http://bioconductor.org/checkResults/release/bioc-LATEST/ramr/ page to
> reflect them. Strangely, this page does not, while
> http://bioconductor.org/packages/3.13/bioc/html/ramr.html shows a new,
> updated version of the package available.
> And also, I know that some issues with package DOIs were reported
> previously, but didn't understand if they are fixed on an individual basis
> or if a general solution will be available. Mine doesn't point to the
> package - https://doi.org/doi:10.18129/B9.bioc.ramr, I wonder if this can
> be fixed.
>

The DOI minting process was suspended in October 2020 but will be revived
this week
and all packages should have working DOIs by end of July.

Thanks


> Best regards,
> Oleksii Nikolaienko
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] pairwiseAlignment strings too long?

[Vincent Carey]

On Fri, Jun 18, 2021 at 5:06 AM csmatyi via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Hello,
>
> I am trying to align two sequences, in DNAString format using the R
> command pairwiseAlignment.
> I keep getting this error:
>
> pairwiseAlignment(si,sj)
> Error in .Call2("XStringSet_align_pairwiseAlignment", pattern, subject,  :
>   max(nchar(pattern) * nchar(subject)) is too big (must be <= 2147483647)
>
> The 2 DNAstrings are si and sj, and are 108,007 bp and 120,698 bp long,
> respectively.
>

The error message states the limitation of the function: the product of
string lengths cannot
exceed  2147483647 but the product of your string lengths is 13036228886,
almost an
order of magnitude too large.

You may have to find a different tool.


> Can someone help me? Are the sequences too long perchance?
>
> Thanks, Matthew
>
> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] bug fix push to Release 3.13 not working for wpm package

[Vincent Carey]

Notice that the pull date for
https://bioconductor.org/checkResults/3.13/bioc-LATEST/ is 6/15.  Your
pushes to RELEASE_3_13 are sound and on my platform vers 1.2.1 of your
package checks out fine in release.
We have reduced the frequency of build/check in release branch as most
sources there do not
change frequently ... see
https://community-bioc.slack.com/archives/CEQ04GKEC/p1621966790034100

On Fri, Jun 18, 2021 at 4:09 AM Hélène Borges <
borges.helene.sop...@gmail.com> wrote:

> Dear Bioc developers,
> I am the maintainer of the wpm package, and I made a bug fix last tuesday.
> I pushed changes on the devel branch and also on the release branch 3.13,
> since it's a bug fix.
> I checked the build reports this morning and curiously, the git push worked
> only for the devel branch, not for the release 3.13 branch.
> I don't understand the difference, because I made the version bump for the
> two: 1.3.2 for the devel branch and 1.2.1 for the release branch. I didn't
> have any error when pushing to upstream RELEASE_3_13...
>
> What can I do to solve this? Did I make the version bump wrong?
> Thanks a lot for your help,
>
> Hélène Borges
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Need Information about Sheep

[Vincent Carey]

Dear Salsabeel Yousuf,

Please use support.bioconductor.org for questions of this kind.

In fact, the question was posed there five years ago:
https://support.bioconductor.org/p/84686/#84690

I will add a comment to that support.bioconductor.org response to bring it
up to date.  Please
check there.




On Sun, Jun 6, 2021 at 5:20 AM salsabeel yousuf 
wrote:

> Hello,
>  hope everything is great at your side. Please tell me I want to use sheep
> instead of pig. How can I change this code
> (BiocManager::install("org.Ss.eg.db"))  for sheep. Please guide me.
>
>
>
> Thanks;
> Regards
> Salsabeel Yousuf
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] SummarizedExperiment assays() gives HDF5Array error in Rstudio

[Vincent Carey]

On Thu, Jun 3, 2021 at 9:11 AM Shraddha Pai 
wrote:

> Hi Vincent,
> Thank you. This is for a workshop with pre-selected versions of R/BioC, so
> I have no control over the release.
> Will try redownloading the data. I just found it puzzling that the
> identical code works in command-line R (ie started from bash shell) but not
> in Rstudio but perhaps they have different ways of caching loaded MAE
> objects?
> Best,Shraddha
>

I neglected to mention that my transcript was developed in RStudio on
Terra, with RStudio 1.4.1106, 2389bc24


>
> On Wed, Jun 2, 2021 at 4:28 PM Vincent Carey 
> wrote:
>
>> You are behind the release and should update.  However, with a reasonably
>> close
>> instance I can't reproduce your error.  I had a flaky download at one
>> point; you might
>> want to reconstitute your brca data.
>>
>> > brca = curatedTCGAData("BRCA", c("miRNASeqGene", "mRNAArray", "RPPAArray", 
>> > "Methylation_methyl27"), dry.run=FALSE)snapshotDate(): 2020-10-27Working 
>> > on: BRCA_miRNASeqGene-20160128see ?curatedTCGAData and 
>> > browseVignettes('curatedTCGAData') for documentationdownloading 1 
>> > resourcesretrieving 1 resource  
>> > |===|
>> >  100%loading from cacheWorking on: BRCA_mRNAArray-20160128see 
>> > ?curatedTCGAData and browseVignettes('curatedTCGAData') for 
>> > documentationdownloading 1 resourcesretrieving 1 resource  
>> > |===|
>> >  100%loading from cacheWorking on: BRCA_RPPAArray-20160128see 
>> > ?curatedTCGAData and browseVignettes('curatedTCGAData') for 
>> > documentationdownloading 1 resourcesretrieving 1 resource  
>> > |===|
>> >  100%loading from cacheWorking on: BRCA_Methylation_methyl27-20160128see 
>> > ?curatedTCGAData and browseVignettes('curatedTCGAData') for 
>> > documentationloading from cachesee ?curatedTCGAData and 
>> > browseVignettes('curatedTCGAData') for documentationloading from 
>> > cacheWorking on: BRCA_colData-20160128see ?curatedTCGAData and 
>> > browseVignettes('curatedTCGAData') for documentationloading from 
>> > cacheWorking on: BRCA_metadata-20160128see ?curatedTCGAData and 
>> > browseVignettes('curatedTCGAData') for documentationloading from 
>> > cacheWorking on: BRCA_sampleMap-20160128see ?curatedTCGAData and 
>> > browseVignettes('curatedTCGAData') for documentationloading from 
>> > cacheharmonizing input:
>>   removing 11654 sampleMap rows not in names(experiments)
>>   removing 1 colData rownames not in sampleMap 'primary'> brcaA 
>> MultiAssayExperiment object of 4 listed
>>  experiments with user-defined names and respective classes.
>>  Containing an ExperimentList class object of length 4:
>>  [1] BRCA_miRNASeqGene-20160128: SummarizedExperiment with 1046 rows and 849 
>> columns
>>  [2] BRCA_mRNAArray-20160128: SummarizedExperiment with 17814 rows and 590 
>> columns
>>  [3] BRCA_RPPAArray-20160128: SummarizedExperiment with 226 rows and 937 
>> columns
>>  [4] BRCA_Methylation_methyl27-20160128: SummarizedExperiment with 27578 
>> rows and 343 columns
>> Functionality:
>>  experiments() - obtain the ExperimentList instance
>>  colData() - the primary/phenotype DataFrame
>>  sampleMap() - the sample coordination DataFrame
>>  `$`, `[`, `[[` - extract colData columns, subset, or experiment
>>  *Format() - convert into a long or wide DataFrame
>>  assays() - convert ExperimentList to a SimpleList of matrices
>>  exportClass() - save all data to files> assay(experiments(brca)[[4]])<27578 
>> x 343> matrix of class DelayedMatrix and type "double":
>>TCGA-A1-A0SD-01A-11D-A112-05 ... TCGA-E2-A15T-01A-11D-A112-05
>> cg0292   0.60555263   .   0.25951246
>> cg2426   0.06197412   .   0.04144839
>> cg3994   0.33345006   .   0.34969161
>> cg5847   0.67217034   .   0.83666264
>> cg6414   NA   .   NA
>>....   ..
>> cg27657283   0.04196141   .   0.03385843
>> cg27661264   0.51756951   .   0.47593756
>> cg27662379  

Re: [Bioc-devel] SummarizedExperiment assays() gives HDF5Array error in Rstudio

[Vincent Carey]

You are behind the release and should update.  However, with a reasonably
close
instance I can't reproduce your error.  I had a flaky download at one
point; you might
want to reconstitute your brca data.

> brca = curatedTCGAData("BRCA", c("miRNASeqGene", "mRNAArray", "RPPAArray", 
> "Methylation_methyl27"), dry.run=FALSE)snapshotDate(): 2020-10-27Working on: 
> BRCA_miRNASeqGene-20160128see ?curatedTCGAData and 
> browseVignettes('curatedTCGAData') for documentationdownloading 1 
> resourcesretrieving 1 resource  
> |===|
>  100%loading from cacheWorking on: BRCA_mRNAArray-20160128see 
> ?curatedTCGAData and browseVignettes('curatedTCGAData') for 
> documentationdownloading 1 resourcesretrieving 1 resource  
> |===|
>  100%loading from cacheWorking on: BRCA_RPPAArray-20160128see 
> ?curatedTCGAData and browseVignettes('curatedTCGAData') for 
> documentationdownloading 1 resourcesretrieving 1 resource  
> |===|
>  100%loading from cacheWorking on: BRCA_Methylation_methyl27-20160128see ?cura
 tedTCGAData and browseVignettes('curatedTCGAData') for documentationloading 
from cachesee ?curatedTCGAData and browseVignettes('curatedTCGAData') for 
documentationloading from cacheWorking on: BRCA_colData-20160128see 
?curatedTCGAData and browseVignettes('curatedTCGAData') for 
documentationloading from cacheWorking on: BRCA_metadata-20160128see 
?curatedTCGAData and browseVignettes('curatedTCGAData') for 
documentationloading from cacheWorking on: BRCA_sampleMap-20160128see 
?curatedTCGAData and browseVignettes('curatedTCGAData') for 
documentationloading from cacheharmonizing input:
  removing 11654 sampleMap rows not in names(experiments)
  removing 1 colData rownames not in sampleMap 'primary'> brcaA
MultiAssayExperiment object of 4 listed
 experiments with user-defined names and respective classes.
 Containing an ExperimentList class object of length 4:
 [1] BRCA_miRNASeqGene-20160128: SummarizedExperiment with 1046 rows
and 849 columns
 [2] BRCA_mRNAArray-20160128: SummarizedExperiment with 17814 rows and
590 columns
 [3] BRCA_RPPAArray-20160128: SummarizedExperiment with 226 rows and 937 columns
 [4] BRCA_Methylation_methyl27-20160128: SummarizedExperiment with
27578 rows and 343 columns
Functionality:
 experiments() - obtain the ExperimentList instance
 colData() - the primary/phenotype DataFrame
 sampleMap() - the sample coordination DataFrame
 `$`, `[`, `[[` - extract colData columns, subset, or experiment
 *Format() - convert into a long or wide DataFrame
 assays() - convert ExperimentList to a SimpleList of matrices
 exportClass() - save all data to files>
assay(experiments(brca)[[4]])<27578 x 343> matrix of class
DelayedMatrix and type "double":
   TCGA-A1-A0SD-01A-11D-A112-05 ... TCGA-E2-A15T-01A-11D-A112-05
cg0292   0.60555263   .   0.25951246
cg2426   0.06197412   .   0.04144839
cg3994   0.33345006   .   0.34969161
cg5847   0.67217034   .   0.83666264
cg6414   NA   .   NA
   ....   ..
cg27657283   0.04196141   .   0.03385843
cg27661264   0.51756951   .   0.47593756
cg27662379   0.01078112   .   0.01157093
cg27662877   0.03112835   .   0.02603354
cg27665659   0.01072116   .
0.01756740> sessionInfo()R version 4.0.3 (2020-10-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04 LTS

Matrix products: default
BLAS/LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.8.so

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
LC_TIME=en_US.UTF-8
 [4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
LC_MESSAGES=C
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=C

attached base packages:
[1] parallel  stats4stats graphics  grDevices utils
datasets  methods   base

other attached packages:
 [1] rhdf5_2.34.0curatedTCGAData_1.12.1
MultiAssayExperiment_1.16.0
 [4] SummarizedExperiment_1.20.0 Biobase_2.50.0
GenomicRanges_1.42.0
 [7] GenomeInfoDb_1.26.7 IRanges_2.24.1
S4Vectors_0.28.1
[10] BiocGenerics_0.36.1 MatrixGenerics_1.2.1
matrixStats_0.59.0
[13] httr_1.4.2  magrittr_2.0.1
AnVIL_1.5.0
[16] dplyr_1.0.6 BiocManager_1.30.15

loaded via a namespace (and not attached):
 [1] bitops_1.0-7  bit64_4.0.5
 [3] rprojroot_2.0.2   tools_4.0.3
 [5] R6_2.5.0

Re: [Bioc-devel] Genomics Extension for SQLite seeking R/bioC co-maintainer

[Vincent Carey]

Thanks Mike, we're having a look.  I haven't found much comparative
benchmarking data by prowling around your site ... am I missing anything?
The colab notebook is helpful.


On Tue, Jun 1, 2021 at 5:07 AM Mike Lin  wrote:

> Dear all,
>
> I'm writing in hopes of recruiting an R/Bioconductor co-maintainer for
> Genomics
> Extension for SQLite , which adds
> several key features to SQLite useful for bioinformatics data management;
> for example:
>
>- streaming read/write compression layer
>- querying compressed databases directly via web/cloud URLs
>- Genomic Range Index for interval overlap queries
>- in-SQL helper functions for manipulating sequences & identifiers
>
> I think this could eventually find use in many Bioconductor features, but
> as a first step, we need the essential bindings package to load the
> extension alongside RSQLite. I'm hoping somebody here might find the
> project promising enough to chip into, as I don't get to use R much in my
> own day-to-day anymore.
>
> The documentation site includes a section on writing language bindings
>  that roadmaps the
> necessary work, which I'd also be happy to work closely together on it.
> Longer term, there are many possible applications to explore, and I also
> anticipate presenting the work in suitable forums which I'd be happy to
> share in.
>
> Please contact me if interested, on this github discussion
> , by email
> d...@mlin.net, or this thread. Alternatively, any feedback/ideas about how
> to make the project useful are most welcome!
>
> Thanks,
> Mike Lin 
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] About the size limitation of the package

[Vincent Carey]

On Wed, May 26, 2021 at 5:55 PM Stuart Lee  wrote:

> Hi You and Lori,
>
> Are fitted models in scope for ExperimentHub? I thought it was more for
> data. Maybe there should be a ModelHub for developers to include trained
> models from papers in their packages?
>
> @You: if that model has been fitted in R take a look at
> https://github.com/tidymodels/butcher for some ways of reducing it’s size.
>

Thanks for these suggestions Stuart!  butcher certainly seems relevant.  I
tried it out on
the adabag output in You's package was able to effectuate some nice
reductions

> tr1 = x$trees[[1]]
> obj_size(tr1)
340,192 B
> obj_size(axe_data(axe_call(axe_fitted(tr1
171,896 B

So this in conjunction with xz compression could make this a moot point
for @You Zhou.

As for the ModelHub, two thoughts.  First, I'd be more inclined at this
stage to partner with a
system like kipoi.org, with fitted models archived there and retrieved by
API as needed by bioc
packages.  I wonder if there are any good examples of this by now.

Second, although I don't feel we have capacity in core to introduce a new
Hub at just this point,
I think we'd be able to help a motivated community-based team to produce
one -- if kipoi suggestion isn't
viable -- utilizing some Azure resources that have been contributed by
Microsoft Genomics.  Interested
parties should write to the list.

I don't see a bioc slack channel devoted to AI/ML and maybe there would be
good traffic on one.
This "task area" could be added to biocchallenges, or could be a topic for
a developer forum meeting.


> Thanks
> Stuart
> 
> From: Bioc-devel  on behalf of Kern,
> Lori 
> Sent: Wednesday, 26 May 2021 10:01 PM
> To: You Zhou ; bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] About the size limitation of the package
>
> Please consider using Experiment Hub to host the large data file. More
> information can be found here:
>
> https://bioconductor.org/packages/devel/bioc/vignettes/AnnotationHub/inst/doc/CreateAHubPackage.html
>
> Cheers,
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of You Zhou
> 
> Sent: Wednesday, May 26, 2021 5:09 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] About the size limitation of the package
>
> Dear Bioc team,
>
>
> I am compiling a package �m6Aboost� and planning to submit it in the
> Bioconductor. This package using a trained machine learning model to
> identify the correct m6A signals from the miCLIP2 data set (more detail
> about this machine learning model can be found in our paper
> https://www.biorxiv.org/content/10.1101/2020.12.20.423675v1).
>
>
>
> Now I meet a problem: the size of this machine learning model is 10 Mb,
> which is bigger than 5 Mb. Since this model is crucial for the package, I
> was wondering whether I can ignore the warning message about the size
> limitation. Thank you : )
>
> Best regards,
> You Zhou
>
> [[alternative HTML version deleted]]
>
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] VariantAnnotation Installation Compile Error

[Vincent Carey]

On Sun, May 23, 2021 at 10:00 PM Dario Strbenac 
wrote:

> Good day,
>
> I apparently have a valid Bioconductor package library but
> VariantAnnotation won't install successfully.
>
> > valid()
> [1] TRUE
> > install("VariantAnnotation")
> Bioconductor version 3.13 (BiocManager 1.30.15), R 4.1.0 (2021-05-18)
> Installing package(s) 'VariantAnnotation'
> trying URL '
> https://bioconductor.org/packages/3.13/bioc/src/contrib/VariantAnnotation_1.38.0.tar.gz
> '
> Content type 'application/x-gzip' length 1726088 bytes (1.6 MB)
> ==
> downloaded 1.6 MB
>
> NULL
>

The NULL here doesn't look good

I see

trying URL '
https://bioconductor.org/packages/3.13/bioc/src/contrib/VariantAnnotation_1.38.0.tar.gz
'
Content type 'application/x-gzip' length 1726088 bytes (1.6 MB)
==
downloaded 1.6 MB

* installing *source* package ‘VariantAnnotation’ ...
** using staged installation
** libs
clang -arch arm64 -I"/Library/Frameworks/R.framework/Resources/include"
-DNDEBUG -D_FILE_OFFSET_BITS=64
-I'/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/S4Vectors/include'
-I'/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/IRanges/include'
-I'/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/XVector/include'
-I'/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Biostrings/include'
-I'/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library/Rhtslib/include'
-I/opt/R/arm64/include   -fPIC  -falign-functions=64 -Wall -g -O2  -c
Biostrings_stubs.c -o Biostrings_stubs.o



> * installing *source* package ‘VariantAnnotation’ ...
> ** using staged installation
> ** libs
> gcc -I"/verona/biostat/software/R-4.1.0/include" -DNDEBUG NULL
> -D_FILE_OFFSET_BITS=64
> -I'/dskh/biostat/software/R-4.1.0/library/S4Vectors/include'
> -I'/dskh/biostat/software/R-4.1.0/library/IRanges/include'
> -I'/dskh/biostat/software/R-4.1.0/library/XVector/include'
> -I'/dskh/biostat/software/R-4.1.0/library/Biostrings/include'
> -I'/dskh/biostat/software/R-4.1.0/library/Rhtslib/include'
> -I/usr/local/include   -fpic  -g -O2  -c Biostrings_stubs.c -o
> Biostrings_stubs.o
> gcc: error: NULL: No such file or directory
> make: *** [/verona/biostat/software/R-4.1.0/etc/Makeconf:168:
> Biostrings_stubs.o] Error 1
> ERROR: compilation failed for package ‘VariantAnnotation’
>
> > sessionInfo()
> R version 4.1.0 (2021-05-18)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Debian GNU/Linux 10 (buster)
> BLAS:   /dskh/biostat/software/R-4.1.0/lib/libRblas.so
> LAPACK: /dskh/biostat/software/R-4.1.0/lib/libRlapack.so
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] VariantAnnotation Installation Compile Error

[Vincent Carey]

Thanks for the report.  I just installed from source successfully with

> sessionInfo()
R version 4.1.0 Patched (2021-05-23 r80366)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04 LTS (fossa-melisa X20)

Matrix products: default
BLAS:   /home/stvjc/R-4-1-dist/lib/R/lib/libRblas.so
LAPACK: /home/stvjc/R-4-1-dist/lib/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats4parallel  stats graphics  grDevices utils datasets
[8] methods   base

other attached packages:
 [1] VariantAnnotation_1.38.0Rsamtools_2.8.0
 [3] Biostrings_2.60.0   XVector_0.32.0
 [5] SummarizedExperiment_1.22.0 Biobase_2.52.0
 [7] GenomicRanges_1.44.0GenomeInfoDb_1.28.0
 [9] IRanges_2.26.0  S4Vectors_0.30.0
[11] MatrixGenerics_1.4.0matrixStats_0.58.0
[13] BiocGenerics_0.38.0

It is good that BiocManager::valid() returns TRUE. Might you be out of temp
space?


On Sun, May 23, 2021 at 10:00 PM Dario Strbenac 
wrote:

> Good day,
>
> I apparently have a valid Bioconductor package library but
> VariantAnnotation won't install successfully.
>
> > valid()
> [1] TRUE
> > install("VariantAnnotation")
> Bioconductor version 3.13 (BiocManager 1.30.15), R 4.1.0 (2021-05-18)
> Installing package(s) 'VariantAnnotation'
> trying URL '
> https://bioconductor.org/packages/3.13/bioc/src/contrib/VariantAnnotation_1.38.0.tar.gz
> '
> Content type 'application/x-gzip' length 1726088 bytes (1.6 MB)
> ==
> downloaded 1.6 MB
>
> NULL
> * installing *source* package ‘VariantAnnotation’ ...
> ** using staged installation
> ** libs
> gcc -I"/verona/biostat/software/R-4.1.0/include" -DNDEBUG NULL
> -D_FILE_OFFSET_BITS=64
> -I'/dskh/biostat/software/R-4.1.0/library/S4Vectors/include'
> -I'/dskh/biostat/software/R-4.1.0/library/IRanges/include'
> -I'/dskh/biostat/software/R-4.1.0/library/XVector/include'
> -I'/dskh/biostat/software/R-4.1.0/library/Biostrings/include'
> -I'/dskh/biostat/software/R-4.1.0/library/Rhtslib/include'
> -I/usr/local/include   -fpic  -g -O2  -c Biostrings_stubs.c -o
> Biostrings_stubs.o
> gcc: error: NULL: No such file or directory
> make: *** [/verona/biostat/software/R-4.1.0/etc/Makeconf:168:
> Biostrings_stubs.o] Error 1
> ERROR: compilation failed for package ‘VariantAnnotation’
>
> > sessionInfo()
> R version 4.1.0 (2021-05-18)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Debian GNU/Linux 10 (buster)
> BLAS:   /dskh/biostat/software/R-4.1.0/lib/libRblas.so
> LAPACK: /dskh/biostat/software/R-4.1.0/lib/libRlapack.so
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] EnMCB reduce dependencies

[Vincent Carey]

IlluminaHumanMethylation450kanno.ilmn12.hg19 is primarily
a collection of data.frames isn't it?  I notice that the
Illum...anno... package itself depends on minfi, which seems
unnecessary.  But perhaps Kasper will comment.

On Fri, May 21, 2021 at 5:32 AM xin wwa  wrote:

> Dear Bioconductor team,
>
> Hi, thank you for reading my email.
>
> Our package has too many dependencies.
> Therefore, we may want to reduce dependencies.
> The main reason is that we use
> minfi::getAnnotation("IlluminaHumanMethylation450kanno.ilmn12.hg19"). And
> minfi package we used has lots of dependencies.
> This is only an annotation table that contains some probe information.
> Is there a way to load the annotation file independent of minfi package?
>
> Thanks in advance. Any help is appreciated!
>
> Regards,
>
> Xin Yu
> Ph.D. student of Biomedical Informatics
> College of Bioinformatics - Huazhong Agricultural University
> whirl...@gmail.com
> yu...@webmail.hzau.edu.cn
> tel: (+86) 186-5313-5769
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] reproducing the BioC package error

[Vincent Carey]

On Wed, May 12, 2021 at 6:14 AM Venu Thatikonda 
wrote:

> Hello all,
>
> I am trying to reproduce the build error of my package
>
>
> https://master.bioconductor.org/checkResults/3.13/bioc-LATEST/ALPS/nebbiolo1-buildsrc.html
>
> As I understand, BioC 3.13 uses R 4.1. However, it seems R 4.1.0 is not yet
> officially released. Are other developers just downloading the R 4.1.0
> devel version and testing their packages?
>

That's correct.  See https://bioconductor.org/developers/release-schedule/
(top) and first
section of https://bioconductor.org/developers/how-to/useDevel/


>
> Thank you & stay safe!
>
> --
> Best regards
> Venu Thatikonda
> https://itsvenu.github.io/
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

[Bioc-devel] avoid updating BiocManager to 1.30.13; provisional fix available

[Vincent Carey]

A problem has been observed with the version of BiocManager
currently available at CRAN.  Do not upgrade to 1.30.13.

If you have already done so, please use

devtools::install_github("Bioconductor/BiocManager", ref="ghost-binary-repo"
)

and restart R; this will provide BiocManager 1.30.13.1

If you run into problems with this please let me know.

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Can't install Bioconductor 3.13 under Windows 10

[Vincent Carey]

This is a known problem and is being investigated.  Thanks for the report.

On Sat, May 8, 2021 at 8:18 AM Gordon K Smyth  wrote:

> I am currently unable to install any Bioconductor 3.13 packages using
> BiocManager for Windows. Here is a sample R session using R 4.1.0beta for
> Windows. Notice the first time I type `install("Biobase")` there is no
> error message but the package is not installed. The second time and
> subsequent times I use install() I get an error message mentioning
> `readRDS`.
>
> Any ideas?
> Thanks
> Gordon
>
> > library(BiocManager)
> Bioconductor version 3.13 (BiocManager 1.30.13), ?BiocManager::install for
> help
> > install("Biobase")
> Bioconductor version 3.13 (BiocManager 1.30.13), R 4.1.0 beta (2021-05-06
> r80268)
> Installing package(s) 'BiocVersion', 'Biobase'
> also installing the dependency ‘BiocGenerics’
>
> > library(Biobase)
> Error in library(Biobase) : there is no package called ‘Biobase’
> > install("Biobase")
> Bioconductor version 3.13 (BiocManager 1.30.13), R 4.1.0 beta (2021-05-06
> r80268)
> Installing package(s) 'BiocVersion', 'Biobase'
> also installing the dependency ‘BiocGenerics’
>
> Error in readRDS(dest) : error reading from connection
> > sessionInfo()
> R version 4.1.0 beta (2021-05-06 r80268)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 18363)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_Australia.1252  LC_CTYPE=English_Australia.1252
> [3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
> [5] LC_TIME=English_Australia.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> other attached packages:
> [1] BiocManager_1.30.13
>
> loaded via a namespace (and not attached):
> [1] compiler_4.1.0 tools_4.1.0
>
> --
> Professor Gordon K Smyth
> Joint Head, Bioinformatics Division
> Walter and Eliza Hall Institute of Medical Research
>
> [WEHI Logo]
>
>
> Walter and Eliza Hall Institute of Medical Research
> 1G Royal Parade Parkville Victoria 3052 Australia
>
> www.wehi.edu.au
>
> Twitter  |  Facebook<
> https://www.facebook.com/WEHIresearch/>  |  Instagram<
> https://www.instagram.com/wehi_research>  |  Youtube<
> https://www.youtube.com/user/WEHImovies>  |  LinkedIn<
> https://www.linkedin.com/company/wehi_research>
>
>
> WEHI acknowledges the Wurundjeri people of the Kulin Nation as the
> traditional owners of the land where our campuses are located and the
> continuing connection to country and community.
>
> Private and confidential
> The content of this e-mail and any attachments may be private and
> confidential, intended only for use of the individual or entity named. If
> you are not the intended recipient of this message you must not read,
> forward, print, copy, disclose, use or store in any way the information
> this e-mail or any attachment contains. If you are not the intended
> recipient, please notify the sender immediately and delete or destroy all
> copies of this e-mail and any attachment.
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] R CMD CHECK warning -

[Vincent Carey]

I'd suggest that this topic be dealt with on the associated contribution
issue.

Please report sessionInfo() when discussing warnings.  I will now make some
comments
on the contribution issue as I am trying to follow up your concerns.

Thanks



On Tue, Apr 27, 2021 at 3:07 AM alan murphy  wrote:

> Hi all,
>
>
> I am working on MungeSumstats(
> https://github.com/neurogenomics/MungeSumstats) which is being considered
> for addition to
>
> Bioconductor (issue:
> https://github.com/Bioconductor/Contributions/issues/2043). To avoid
> importing large reference genomes
>
> in my package, I recently put them in as suggests and made a custom check
> to ensure they are installed. However, I am now
>
> getting an odd warning on the Bioconductor windows machine:
>
> * checking whether package 'MungeSumstats' can be installed ... WARNING
> Found the following significant warnings:
>   Warning: no function found corresponding to methods exports from
> 'S4Vectors' for: 'combineRows'
>
> Note, I don't get any warnings locally or on the other two machines. Has
> anyone seen this before? I have S4Vectors down in my
> suggests as it is used in the reference genome packages (for example, see
> SNPlocs.Hsapiens.dbSNP144.GRCh38:
> https://bioconductor.org/packages/release/data/annotation/html/SNPlocs.Hsapiens.dbSNP144.GRCh38.html)
> but I'm not sure how it
> even relates to combineRows?
>
> Any help would be massively appreciated!
>
> Kind regards,
> Alan.
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] biocLite not installing

[Vincent Carey]

Dear Dr Diaz:

This email list is for development of software in Bioconductor.  Questions
about basic functionality should go to
support.bioconductor.org -- please visit that site and make an account.

For your specific question please note the message


> source("https://bioconductor.org/biocLite.R;)
 Error: With R version 3.5 or greater, install Bioconductor packages using
BiocManager; see https://bioconductor.org/install

biocLite is not used with the version of R you are using.  If you have
further questions please post
to support.bioconductor.org.

Thanks!



On Fri, Apr 16, 2021 at 6:30 AM Diaz, Josue E. 
wrote:

> > BiocManager::install("biocLite")Bioconductor version 3.12 (BiocManager
> 1.30.12), R 4.0.4 (2021-02-15)Installing package(s) 'biocLite'Installation
> path not writeable, unable to update packages: broom, callr, cli, cpp11,
> dbplyr,  diffobj, pkgload, processx, reprex, survival, tinytex,
> vctrsWarning message:package ‘biocLite’ is not available for this version
> of RA version of this package for your version of R might be available
> elsewhere,see the ideas athttps://
> cran.r-project.org/doc/manuals/r-patched/R-admin.html#Installing-packages
>
> > source("https://bioconductor.org/biocLite.R;)
>  Error: With R version 3.5 or greater, install Bioconductor packages using
> BiocManager; see https://bioconductor.org/install
> > biocLite(pkgs=c("Biobase", "IRanges", "AnnotationDbi"),
>  suppressUpdates=FALSE, suppressAutoUpdate=FALSE, siteRepos=character(),
> ask=TRUE, ...)Error in biocLite(pkgs = c("Biobase", "IRanges",
> "AnnotationDbi"), suppressUpdates = FALSE,  :   could not find function
> "biocLite"
>
>  > BiocManager::install()Bioconductor version
>  3.12 (BiocManager 1.30.12), R 4.0.4 (2021-02-15)Installation path not
> writeable, unable to update packages: broom, callr, cli, cpp11, dbplyr,
> diffobj, pkgload, processx, reprex, survival, tinytex, vctrs
> > BiocManager::install()Bioconductor
> version 3.12 (BiocManager 1.30.12), R 4.0.4 (2021-02-15)Installation path
> not writeable, unable to update packages: broom, callr, cli, cpp11,
> dbplyr,  diffobj, pkgload, processx, reprex, survival, tinytex, vctrs
>
> Josue Diaz
> Graduate Research Fellow | Dr. Leah McHale Lab
> Center for Applied Plant SciencesTranslational Plant Sciences Graduate
> Program
>
> 326 Kottman Hall, 2021 Coffey Road, Columbus, OH 43212
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and ExperimentHub

[Vincent Carey]

The experience:

> ah = AnnotationHub()
Error in AnnotationHub() :
  As of AnnotationHub (>2.23.2), default caching location has changed.
  Problematic cache: /home/stvjc/.cache/AnnotationHub
  To continue with default caching location,
  See AnnotationHub vignette TroubleshootingTheCache section on 'Default
Caching Location Update'

Enter a frame number, or 0 to exit

1: AnnotationHub()

Selection: 0
> rappdirs::user_cache_dir(appname="BiocFileCache")
[1] "~/.cache/BiocFileCache"
> rappdirs::user_cache_dir(appname="AnnotationHub")
[1] "~/.cache/AnnotationHub"   # solution from vignette:  850MB moved very
quickly...
> olddir <- path.expand(rappdirs::user_cache_dir(appname="AnnotationHub"))
> newdir <- tools::R_user_dir("AnnotationHub", which="cache")
> dir.create(path=newdir, recursive=TRUE)
> files <- list.files(olddir, full.names =TRUE)
> moveres <- vapply(files,
+ FUN=function(fl){
+   filename = basename(fl)
+   newname = file.path(newdir, filename)
+   file.rename(fl, newname)
+ },
+ FUN.VALUE = logical(1))
> if(all(moveres)) unlink(olddir, recursive=TRUE)
> ah = AnnotationHub()  # try again
snapshotDate(): 2021-03-15


On Wed, Apr 7, 2021 at 12:03 PM Vincent Carey 
wrote:

> For convenience here are relevant sections of the new vignette.   Give it
> a try and let us know.  This is "devel".
>
> 4Default Caching Location Update
>
> As of BiocFileCache version > 1.15.1, the default caching location has
> changed. The default cache is now controlled by the function
> tools::R_user_dir instead of rappdirs::user_cache_dir. Users who have
> utilized the default BiocFileCache, to continue using the created cache,
> must move the cache and its files to the new default location or delete the
> old cache and have to redownload any previous files.
> 4.1Option 1: Moving Files
>
> The following steps can be used to move the files to the new location:
>
>1.
>
>Determine the old location by running the following in R
>rappdirs::user_cache_dir(appname="BiocFileCache")
>2.
>
>Determine the new location by running the following in R 
> tools::R_user_dir("BiocFileCache",
>which="cache")
>3.
>
>Move the files to the new location. You can do this manually or do the
>following steps in R. Remember if you have a lot of cached files, this may
>take awhile.
>
> olddir <- path.expand(rappdirs::user_cache_dir(appname="BiocFileCache"))
> newdir <- tools::R_user_dir("BiocFileCache", which="cache")
> dir.create(path=newdir, recursive=TRUE)
> files <- list.files(olddir, full.names =TRUE)
> moveres <- vapply(files,
> FUN=function(fl){
>   filename = basename(fl)
>   newname = file.path(newdir, filename)
>   file.rename(fl, newname)
> },
> FUN.VALUE = logical(1))
> if(all(moveres)) unlink(olddir, recursive=TRUE)
>
> 4.2Option 2: Specify a Cache Location Explicitly
>
> Users may always specify a unique caching location by providing the cache 
> argument
> to the BiocFileCache constructor; however users must always specify this
> location as it will not be recognized by default in subsequent runs.
>
> Alternatively, the default caching location may also be controlled by a
> user-wise or system-wide environment variable. Users may set the
> environment variable BFC_CACHE to the old location to continue using as
> default location.
>
> On Wed, Apr 7, 2021 at 11:51 AM Kern, Lori 
> wrote:
>
>> There is no guarantee we would be under the right user to have
>> permissions to move the cache automatically and would not want to leave it
>> in a broken state.
>>
>> We could start a fresh cache in the new location but there would be no
>> way to combined an old cache and a new cache and there would be no way to
>> warn people before starting the new cache to give them an opportunity to
>> move the old cache to the new location.
>>
>> This should not affect any cache that is explicitly stated with a
>> different name in the constructor or using environment variables;  only in
>> the case of BiocFileCache() .  Most package specific caches created their
>> own cache in the constructor so it should not cause the ERROR in that case.
>>
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Comprehensive Cancer Center
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>>
>

Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and ExperimentHub

[Vincent Carey]

For convenience here are relevant sections of the new vignette.   Give it a
try and let us know.  This is "devel".

4Default Caching Location Update

As of BiocFileCache version > 1.15.1, the default caching location has
changed. The default cache is now controlled by the function
tools::R_user_dir instead of rappdirs::user_cache_dir. Users who have
utilized the default BiocFileCache, to continue using the created cache,
must move the cache and its files to the new default location or delete the
old cache and have to redownload any previous files.
4.1Option 1: Moving Files

The following steps can be used to move the files to the new location:

   1.

   Determine the old location by running the following in R
   rappdirs::user_cache_dir(appname="BiocFileCache")
   2.

   Determine the new location by running the following in R
tools::R_user_dir("BiocFileCache",
   which="cache")
   3.

   Move the files to the new location. You can do this manually or do the
   following steps in R. Remember if you have a lot of cached files, this may
   take awhile.

olddir <- path.expand(rappdirs::user_cache_dir(appname="BiocFileCache"))
newdir <- tools::R_user_dir("BiocFileCache", which="cache")
dir.create(path=newdir, recursive=TRUE)
files <- list.files(olddir, full.names =TRUE)
moveres <- vapply(files,
FUN=function(fl){
  filename = basename(fl)
  newname = file.path(newdir, filename)
  file.rename(fl, newname)
},
FUN.VALUE = logical(1))
if(all(moveres)) unlink(olddir, recursive=TRUE)

4.2Option 2: Specify a Cache Location Explicitly

Users may always specify a unique caching location by providing the
cache argument
to the BiocFileCache constructor; however users must always specify this
location as it will not be recognized by default in subsequent runs.

Alternatively, the default caching location may also be controlled by a
user-wise or system-wide environment variable. Users may set the
environment variable BFC_CACHE to the old location to continue using as
default location.

On Wed, Apr 7, 2021 at 11:51 AM Kern, Lori 
wrote:

> There is no guarantee we would be under the right user to have permissions
> to move the cache automatically and would not want to leave it in a broken
> state.
>
> We could start a fresh cache in the new location but there would be no way
> to combined an old cache and a new cache and there would be no way to warn
> people before starting the new cache to give them an opportunity to move
> the old cache to the new location.
>
> This should not affect any cache that is explicitly stated with a
> different name in the constructor or using environment variables;  only in
> the case of BiocFileCache() .  Most package specific caches created their
> own cache in the constructor so it should not cause the ERROR in that case.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Aaron Lun 
> Sent: Wednesday, April 7, 2021 11:41 AM
> To: Kern, Lori 
> Cc: bioc-devel@r-project.org 
> Subject: Re: [Bioc-devel] Updates to BiocFileCache, AnnotationHub, and
> ExperimentHub
>
> Woah, I missed the part where you said that there would be an error.
>
> This does not sound good. Users are going to flip out, especially when
> EHub and AHub are not visible dependencies (e.g., scRNAseq, celldex).
> It also sounds completely unnecessary for EHub and AHub given that the
> new cache can just be populated by fresh downloads. Similarly,
> BiocFileCache::bfcrpath should not be affected, and people using that
> shouldn't be getting an error.
>
> Why not just move the old default cache into the new location
> automatically? This seems like the simplest solution given that
> everyone accessing BFC resources should be doing so through the BFC
> API. And most files are not position-dependent, unless people are
> putting shared libraries in there.
>
> But even if you can't, an error is just too much. We use BiocFileCache
> a lot in our company infrastructure and the brown stuff will hit the
> fan if we have to find every old default cache and delete it. The
> package should handle this for us.
>
> -A
>
> On Wed, Apr 7, 2021 at 4:46 AM Kern, Lori 
> wrote:
> >
> > Mostly to lighten the dependency tree using tools that is built in with
> R would remove one additional dependency.  Also clarity; the tools
> directory adds an R folder for distinction that they are used with R
> packages which seemed like if a user was ever investigating, they would
> have a better idea where those files came from.
> >
> >
> > Lori Shepherd
> >
> > Bioconductor Core Team
> >
> > Roswell Park Comprehensive Cancer Center
> >
> > Department of Biostatistics & Bioinformatics
> >
> > Elm & Carlton Streets
> >
> > Buffalo, New York 14263
> >
> > 
> > From: 

Re: [Bioc-devel] docker build failure when installing dependencies

[Vincent Carey]

note that diffcyt does not currently build at
https://bioconductor.org/checkResults/3.13/bioc-LATEST/ -- its errors need
to be
repaired for your build to succeed



On Tue, Mar 9, 2021 at 11:07 AM Reto Gerber via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Dear all,
>
> I would like to reproduce a build error (on Bioc devel) using docker. The
> issue is that the docker image fails to build. I use the following
> Dockerfile:
>
> > FROM bioconductor/bioconductor_docker:devel
> > RUN install2.r --error broom.mixed\
> > BiocManager \
> > devtools \
> > dirmult\
> > fitdistrplus\
> > lme4\
> > MASS\
> > mice\
> > multcomp\
> > survival\
> > knitr\
> > rmarkdown\
> > testthat
> > RUN R -e ' BiocManager::install(version = '3.13',ask=FALSE) ;
> BiocManager::install(c("BiocParallel","BiocStyle","diffcyt","S4Vectors","SummarizedExperiment"),version="3.13",ask=FALSE)'
>
> And then build with:
>
> > docker build --pull .
>
> Which gives the following error:
>
> > 1: In install.packages(...) :
> > installation of package ‘flowWorkspace’ had non-zero exit status
> > 2: In install.packages(...) :
> > installation of package ‘ggcyto’ had non-zero exit status
> > 3: In install.packages(...) :
> > installation of package ‘flowStats’ had non-zero exit status
> > 4: In install.packages(...) :
> > installation of package ‘openCyto’ had non-zero exit status
> > 5: In install.packages(...) :
> > installation of package ‘CytoML’ had non-zero exit status
> > 6: In install.packages(...) :
> > installation of package ‘FlowSOM’ had non-zero exit status
> > 7: In install.packages(...) :
> > installation of package ‘diffcyt’ had non-zero exit status
>
> What am I doing wrong? (according to the build report on malbec2 this
> should work)
> Thanks for the help!
>
> (I try to reproduce the error for the package censcyt
> http://bioconductor.org/checkResults/devel/bioc-LATEST/censcyt/ )
>
> Best,
> Reto
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Moving minfi classes definition to a lighter package

[Vincent Carey]

i advocated pkgnet and included a png but email seems to have been rejected


On Wed, Mar 3, 2021 at 7:29 AM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> I am happy to engage in a discussion about this, although I'm not sure that
> I am ultimately interested in having two packages.
>
> But first I would like to look at some dependency graphs. I am wondering
> what makes the dependency tree this big (and my tree is smaller than yours,
> but still big: library(minfi) gives me 16 attached packages and 89 loaded
> packages for the current release). This includes some part of the tidyverse
> which we don't really use much though (and which could probably get removed
> from the package with almost no work).
>
> What's the current best tool for dependency graphs in Bioconductor?
> pkgDepTools?
>
> Best,
> Kasper
>
> On Mon, Mar 1, 2021 at 6:24 PM Carlos Ruiz 
> wrote:
>
> > Dear Bioc developers,
> >
> > I have been developing different packages to analyze DNA methylation. In
> > all of them, I have used minfi's class GenomicRatioSet to manage DNA
> > methylation data, in order to take profit of the features of
> > RangedSummarizedExperiment.
> >
> > Although I am very happy with the potential of the class, importing its
> > definition from minfi, makes me add the package to imports. As minfi has
> a
> > high number of dependencies (129 in the current release), my packages end
> > up having hundreds of dependencies too. This is particularly problematic
> as
> > I do not use any of the other functions of minfi.
> >
> > I am wondering whether it could be possible to move minfi's class (or at
> > least GenomicRatioSet) to a lighter package, so people developing
> packages
> > on DNA methylation could rely on this class without having to import the
> > whole minfi package and its dependencies.
> >
> > Thank you very much,
> > --
> >
> > Carlos Ruiz
> >
> > --
> >
> >
> > This message is intended exclusively for its addressee and may contain
> > information that is CONFIDENTIAL and protected by professional privilege.
> > If
> > you are not the intended recipient you are hereby notified that any
> > dissemination, copy or disclosure of this communication is strictly
> > prohibited
> > by law. If this message has been received in error, please
> > immediately notify
> > us via e-mail and delete it.
> >
> >
> >
> > DATA PROTECTION. We
> > inform you that your personal data, including your
> > e-mail address and data
> > included in your email correspondence, are included in
> > the ISGlobal
> > Foundation files. Your personal data will be used for the purpose
> > of
> > contacting you and sending information on the activities of the above
> > foundations. You can exercise your rights of access, rectification,
> > cancellation and opposition by contacting the following address:
> > l...@isglobal.org . ISGlobal
> > Privacy Policy at
> > www.isglobal.org .
> >
> >
> >
> >
> >
> -
> >
> > CONFIDENCIALIDAD. Este mensaje y sus anexos se dirigen exclusivamente a
> > su
> > destinatario y puede contener información confidencial, por lo que la
> > utilización,
> > divulgación y/o copia sin autorización está prohibida por la
> > legislación
> > vigente. Si ha recibido este mensaje por error, le rogamos lo
> > comunique
> > inmediatamente por esta misma vía y proceda a su destrucción.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > PROTECCIÓN DE DATOS. Sus datos de carácter personal utilizados en este
> > envío, incluida su dirección de e-mail, forman parte de ficheros de
> > titularidad
> > de la Fundación ISGlobal  para cualquier
> > finalidades de
> > contacto, relación institucional y/o envío de información sobre
> > sus
> > actividades. Los datos que usted nos pueda facilitar contestando este
> > correo quedarán incorporados en los correspondientes ficheros,
> autorizando
> > el
> > uso de su dirección de e-mail para las finalidades citadas. Puede
> > ejercer los
> > derechos de acceso, rectificación, cancelación y oposición
> > dirigiéndose a l...@isglobal.org * *. Política
> > de
> > privacidad
> > en www.isglobal.org .
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > 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
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Remotes in DESCRIPTION not supported for BioC?

[Vincent Carey]

My understanding is that we will not permit dependencies outside of Bioc or
CRAN.  If a repository
is created that is at least as rigorous in package admission as CRAN,
perhaps it needs to be
considered.  If there are details known about alternate repositories that
we should learn about, please supply.

On Tue, Mar 2, 2021 at 1:20 PM Henrik Bengtsson 
wrote:

> Related: Does Bioconductor support 'Additional_repositories'? From RWE:
>
> The ‘Additional_repositories’ field is a comma-separated list of
> repository URLs where the packages named in the other fields may be
> found. It is currently used by R CMD check to check that the packages
> can be found, at least as source packages (which can be installed on
> any platform).
>
> FWIW, CRAN allows/supports them (I've only used them for packages
> under 'Suggests:').
>
> /Henrik
>
> On Tue, Mar 2, 2021 at 4:02 AM Rainer Johannes
>  wrote:
> >
> > thanks for the quick reply Lori!
> >
> > OK, so we will have to submit the package to Bioc ASAP.
> >
> > cheers, jo
> >
> > > On 2 Mar 2021, at 12:51, Kern, Lori 
> wrote:
> > >
> > > Currently the builders do not allow the user of remotes and you would
> have to wait for it to be submitted to CRAN or Bioconductor.  All
> Bioconductor dependencies must be on CRAN or Bioconductor.
> > >
> > > Get Outlook for iOS
> > > From: Bioc-devel  on behalf of
> Rainer Johannes 
> > > Sent: Tuesday, March 2, 2021 4:36:05 AM
> > > To: bioc-devel 
> > > Subject: [Bioc-devel] Remotes in DESCRIPTION not supported for BioC?
> > >
> > > Dear All!
> > >
> > > in one of the xcms vignettes we are using a R package which is not yet
> in Bioconductor and I added
> > >
> > > Remotes:
> > > RforMassSpectrometry/MsBackendMgf
> > >
> > > to the DESCRIPTION thinking that on the BioC build machines the
> package might get installed (from github). It does apparently not as we get
> ERROR for this vignette. Is there any way I can use a non-Bioconductor and
> non-CRAN package or do I have to wait until the package is included in
> Bioconductor?
> > >
> > > thanks for any feedback!
> > >
> > > cheers, jo
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > >
> https://secure-web.cisco.com/1H1jWIWyghkLhLM5RAXwwfoWK4PlOlae4Pc1-a_NRbOIOuLSLHtGAyInV-z8t0fCgCfVH0nxURKnBN77cdDWaaKfCoZMnqX4XshZNWoi44Ko2dWmnDvV5BjARxeduRCCmoKigDovJkvgYgbecL-t9v9m2HGULeKeb9va8J3NlYFXnVkCDGyzsNgbeZSN2VlWCKhLL1vQqlJEiglEPQraiCYfRjZdnxkQsRcLPnIkfvjbIHJWHFz0LYJRGav4iCiARcWCn0Uo0qe8ieknAiGloqMR2HJHD6oUNCdG8v7oYy73oVejgIqxYBbvJsrztDawr/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
> > >
> > >
> > > This email message may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited. If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Devel version of R for package development

[Vincent Carey]

On Tue, Feb 23, 2021 at 11:25 AM Matesi, Gregory <
gregory.mat...@ucdenver.edu> wrote:

> Hello all,
>
> I had a question about package development using the devel version of
> bioconductor. We are encouraged to add dependence to the version of R that
> is used by the devel branch of Bioconductor, e.g. R version 4.1. This means
> developing using a version of R that is not released yet. Users downloading
> our package from Github get the following error message.
> Do we revert to the current R version after the package is out of the
> development stage? Or are we supposed to leave the dependence on the devel
> version of R?
>

Your github repo can have branches that address the different R versions
and you can use the ref= parameter of install_github to get the appropriate
one.

There are other approaches and others will surely provide additional
guidance.


>
> > install_github("https://github.com/hendriau/Summix.git;)
>
> Installing package into ‘C:/Users/Gregory/Documents/R/win-library/4.0’
> (as ‘lib’ is unspecified)
> ERROR: this R is version 4.0.3, package 'Summix' requires R >= 4.1
> Error: Failed to install 'Summix' from GitHub:
>   (converted from warning) installation of package
> ‘C:/Users/Gregory/AppData/Local/Temp/RtmpMTpKWs/file3ce813c62fbf/Summix_0.99.9.tar.gz’
> had non-zero exit status
>
> Thank you,
> Greg
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] EWCE Bioconductor package

[Vincent Carey]

EWCE may need to be reviewed for reinclusion.  I tried to check on R-devel
with the repo you mentioned.  Do you
have a current personal repo that passes check with Bioc 3.13/R-devel?

Quitting from lines 220-223 (EWCE.Rmd)
Error: processing vignette 'EWCE.Rmd' failed with diagnostics:
Invalid attribute(s): percentage_gc_content
Please use the function 'listAttributes' to get valid attribute names
--- failed re-building ‘EWCE.Rmd’

On Thu, Feb 11, 2021 at 9:41 AM Murphy, Alan E 
wrote:

> Hi all,
>
> My apologies in advance if this is not the correct mailing list for this
> question, regarding development to the EWCE Bioconductor package.
>
> I work as part of Dr. Nathan Skene's group who submitted the package EWCE<
> https://bioconductor.riken.jp/packages/3.5/bioc/html/EWCE.html#since> to
> Bioconductor some years ago. The package fell out of maintenance and as
> such was deprecated from Bioconductor 3.6. We are working to update and
> hopefully, reinstate the package but are running into issues when pushing
> any changes to Bioconductor. We have been following instructions here<
> http://bioconductor.org/developers/how-to/git/sync-existing-repositories/>
> to try and sync our Github updates with the Bioconductor version but can't
> seem to push the new, merged version to Bioconductor.
>
> To test the cause of the issue, we cloned the repo:
>
> git clone https://git.bioconductor.org/packages/EWCE
>
> And updated the version of the package in the DESCRIPTION file and tried
> pushing the change, using Nathan's account which is associated with the
> package. However, we still can't push to Bioconductor, getting the error:
>
>
> -bash-4.2$ git push origin master
> FATAL: W any packages/EWCE n.skene DENIED by fallthru
> (or you mis-spelled the reponame)
> fatal: Could not read from remote repository.Please make sure you have the
> correct access rights
> and the repository exists.
>
> It appears it does recognise Nathan's account but doesn't think he has
> access rights to the repo. It is worth noting that EWCE is also not listed
> on his account's webpage.
>
> We are wondering if this issue is caused by EWCE being deprecated and if
> so, what are the necessary steps to reinstate it?
>
> Kind regards,
> Alan.
>
> Alan Murphy
> Bioinformatician
> Neurogenomics lab
> UK Dementia Research Institute
> Imperial College London
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] EWCE Bioconductor package

[Vincent Carey]

Please disregard my note.  As Lori has indicated formal review must proceed
before reinclusion.

On Thu, Feb 11, 2021 at 9:51 AM Vincent Carey 
wrote:

> EWCE may need to be reviewed for reinclusion.  I tried to check on R-devel
> with the repo you mentioned.  Do you
> have a current personal repo that passes check with Bioc 3.13/R-devel?
>
> Quitting from lines 220-223 (EWCE.Rmd)
> Error: processing vignette 'EWCE.Rmd' failed with diagnostics:
> Invalid attribute(s): percentage_gc_content
> Please use the function 'listAttributes' to get valid attribute names
> --- failed re-building ‘EWCE.Rmd’
>
> On Thu, Feb 11, 2021 at 9:41 AM Murphy, Alan E 
> wrote:
>
>> Hi all,
>>
>> My apologies in advance if this is not the correct mailing list for this
>> question, regarding development to the EWCE Bioconductor package.
>>
>> I work as part of Dr. Nathan Skene's group who submitted the package EWCE<
>> https://bioconductor.riken.jp/packages/3.5/bioc/html/EWCE.html#since> to
>> Bioconductor some years ago. The package fell out of maintenance and as
>> such was deprecated from Bioconductor 3.6. We are working to update and
>> hopefully, reinstate the package but are running into issues when pushing
>> any changes to Bioconductor. We have been following instructions here<
>> http://bioconductor.org/developers/how-to/git/sync-existing-repositories/>
>> to try and sync our Github updates with the Bioconductor version but can't
>> seem to push the new, merged version to Bioconductor.
>>
>> To test the cause of the issue, we cloned the repo:
>>
>> git clone https://git.bioconductor.org/packages/EWCE
>>
>> And updated the version of the package in the DESCRIPTION file and tried
>> pushing the change, using Nathan's account which is associated with the
>> package. However, we still can't push to Bioconductor, getting the error:
>>
>>
>> -bash-4.2$ git push origin master
>> FATAL: W any packages/EWCE n.skene DENIED by fallthru
>> (or you mis-spelled the reponame)
>> fatal: Could not read from remote repository.Please make sure you have
>> the correct access rights
>> and the repository exists.
>>
>> It appears it does recognise Nathan's account but doesn't think he has
>> access rights to the repo. It is worth noting that EWCE is also not listed
>> on his account's webpage.
>>
>> We are wondering if this issue is caused by EWCE being deprecated and if
>> so, what are the necessary steps to reinstate it?
>>
>> Kind regards,
>> Alan.
>>
>> Alan Murphy
>> Bioinformatician
>> Neurogenomics lab
>> UK Dementia Research Institute
>> Imperial College London
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] How to integrate code from a package not available on bioconductor

[Vincent Carey]

It is wise to be careful here.  If we don't know the provenance of the code
in github it might actually be someone else's.
It reminds me of the Numerical Recipes events, in which folks redistributed
proprietary code without permission.
What repo are we talking about anyway?

On Wed, Feb 10, 2021 at 12:38 PM Martin Morgan 
wrote:

> I don’t know what the legal requirement is.
>
> As a human if I hadn’t given explicit consent I’d like to be asked. And if
> I had used someone else’s code I’d like it to be transparent that my use
> was legitimate, and a private exchange of email between me and the other
> individual consenting to use their code wouldn’t be transparent enough.
> Hopefully I’m not being hypocritical here.
>
> Martin
>
> From: Ana Carolina Leote 
> Date: Wednesday, February 10, 2021 at 10:24 AM
> To: "Kern, Lori" 
> Cc: Martin Morgan , Wolfgang Huber <
> wolfgang.hu...@embl.org>, "bioc-devel@r-project.org" <
> bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] How to integrate code from a package not
> available on bioconductor
>
> My motivation to include this package is that my own package includes, but
> is not limited to, an ensemble of different packages that attempt to solve
> the same problem, besides my own solution, since I did some work showing
> they all have their pros and cons. At the moment my package does not
> include this one, because of all the problems here raised, but since it is
> arguably more popular than all other "alternative" packages, I felt I
> should include it. This is why using an alternative package unfortunately
> does not solve my problem. I also looked in the page Lori shared but this
> package is not there. However you do raise very valid points. I think I
> need to weigh the cost of changing the code against the additional
> usefulness my package can gain more carefully than I did so far.
>
> I do have one additional question, though. Martin mentioned the license
> compatibility. There is no license at all in the GitHub repository of this
> package. I did some searching but I'm not sure what the default GitHub
> copyright means for bioconductor distribution. Does it mean I am not
> allowed to include this code in case I do wish to go forward with taking
> the code "as is"?
>
> Thanks again for all your helpful responses. It's great as a new developer
> to have such support.
>
> Best,
> Carolina
>
> Ana Carolina Leote
> MSc. Biological Engineering
> PhD student at the Cologne Graduate School for Ageing Research
> Cellular networks and systems biology (Beyer group), CECAD Research Center
> https://www.linkedin.com/in/anacarolinaleote/
>
>
> On Wed, Feb 10, 2021 at 3:50 PM Kern, Lori  > wrote:
> Have you looked at some of the scRNA packages that are already on
> Bioconductor to see if there is similar functionality in an existing
> package already accepted?
> You can search for packages that have scRNA in the package name or title
> on this page:
> http://bioconductor.org/packages/release/BiocViews.html#___Software
>
> depending there is also a single cell workflow that might point to similar
> functionality
>
> http://bioconductor.org/packages/release/workflows/html/simpleSingleCell.html
>
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  bioc-devel-boun...@r-project.org>> on behalf of Martin Morgan <
> mtmorgan.b...@gmail.com>
> Sent: Wednesday, February 10, 2021 9:36 AM
> To: Ana Carolina Leote  anacarolinale...@gmail.com>>; Wolfgang Huber  >
> Cc: bioc-devel@r-project.org <
> bioc-devel@r-project.org>
> Subject: Re: [Bioc-devel] How to integrate code from a package not
> available on bioconductor
>
> If the package is already widely used, then I guess it provides useful
> functionality, and so your package doesn't have to provide that
> functionality, so perhaps a better solution is to refer users to the
> unsupported package in your vignette??
>
> What you say about not being maintained in over a year is probably the
> main concern with using code that is not in CRAN or Bioconductor. Already
> the code could be buggy, not well tested, and poorly documented (even if
> widely used! and of course the code / documentation could be excellent...)
> because it has not been subject to regular R CMD check etc or to initial
> review. And now the original author of the code is not maintaining it, so
> *you* have to fully understand it so that you can address bugs etc. As a
> 'developer' this could be my worst nightmare -- having to spend my time
> cursing at code somebody else wrote, instead of cursing at my own code!
>
> The license of the package needs to permit use of the code, or may
> restrict 

Re: [Bioc-devel] How to integrate code from a package not available on bioconductor

[Vincent Carey]

On Wed, Feb 10, 2021 at 8:32 AM Kern, Lori 
wrote:

> Have you reached out to the maintainer of the github package to see if
> they would plan on submitting to CRAN or Bioconductor?
> If they do not,  you could see if they are okay with you including the
> code in your package and then clearly indicate their authorship in the man
> pages and by giving contributor credit in the DESCRIPTION. They might also
> include CITATION information in their package to include?
>
> Others might have additional thoughts?
>
>
This is what I would have suggested.  Also, if the github author needs
encouragement about submission to a regulated
ecosystem, have them get in touch with us.


> Cheers,
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of Ana
> Carolina Leote 
> Sent: Wednesday, February 10, 2021 5:14 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] How to integrate code from a package not available
> on bioconductor
>
> Dear all,
>
> I am a package maintainer and would like to add a functionality that
> depends on another package which is not available in bioconductor, only via
> GitHub. I would like to make the necessary changes in order to be able to
> use their code in my package. Can anyone point me towards the best way to
> proceed without undermining the authorship of the original developers? Is
> copying their code to my package and editing it to bioconductor standards
> appropriate?
>
> Thank you and best wishes,
> Carolina
>
> *Ana Carolina Leote*
> *MSc. Biological Engineering*
> *PhD student at the Cologne Graduate School for Ageing Research*
> *Cellular networks and systems biology (Beyer group), **CECAD Research
> Center*
>
> https://secure-web.cisco.com/1sN_yjFZ4rXsNHMf8Fp8CJTySgKw-1exyK2uoJVgve2HB-ffaKVZpjVqnqKkiHfvj-8XfBD5L-E-u5CSB1GVD7eouovHeu4HCMh60N2H2o2WA8SOPodHnGfUgo8J3fWYeoSrQCiNJ5M4yE2VTnUi-WGlGdJeBDFxKTQwTFVThCjoTyAwk1tTdVAznZxVTGkCNBmBuV1Na-a0-81QaIYra4grO9-57FesPlxZIA0WUU9icoS3LgqlPTUhsmLZUM0NmejCSrTNSDA9AzDs7tB66TW4lBTvaNpOHMrk5wPCYIPckLqpDkVL3HnRSiWmXdWJE/https%3A%2F%2Fwww.linkedin.com%2Fin%2Fanacarolinaleote%2F
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1vxzYOt1Hk0jYyShxe8B714l2GGAvh6Qvfo2Ey_49Ro47iSw83aMqNIB5Qv3keiqGApswE2x6TuWzoZjp-NJuEJcrt-skDYLR1Lsd0m1gCdOno-5vOXu1DHnuKsRkZQEyXRX00TjWpnBjbIwuJq5ll1xYmpurSpXNAagbyUQpcfZ136DgLhfGEM63BY-2KzMOwYsXqzpFhqcGhYhR1BkRDJBlIK7NjrhbsQ_8f4Hn2n7yvll4i20POhhaeiLBMZwwu0HXiWtT8v6VNA8pbxf7YxHpISCef2JJErtEjx21uA1ZQxeTNYg3X_37zZDJYGcZ/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] How to replace KEGG.db

[Vincent Carey]

I did a little work in this area, relieving GenomicRanges of dependency on
KEGG.db.

For your example, which does not run (?), I would suggest
a) avoiding the use of the old environments like hgu95av2PATH2PROBE,
replacing
this with AnnotationDbi::select calls
b) replace the KEGG.db invocations with KEGGREST equivalents.

As an example, using AnnotationDbi, hgu95av2.db, and KEGGREST

> select(hgu95av2.db, "JUNB", keytype="SYMBOL", columns=c("PROBEID",
"PATH"))
'select()' returned 1:many mapping between keys and columns
  SYMBOL   PROBEID  PATH
1   JUNB 2049_s_at 04380
2   JUNB  32786_at 04380
> keggFind("pathway", "04380")
   path:map04380
"Osteoclast differentiation"


On Mon, Feb 1, 2021 at 11:27 AM Claudio Lottaz <
claudio.lot...@klinik.uni-regensburg.de> wrote:

> Hi all,
>
> In my package adSplit, I use microarray annotation packages like
> hgu95av2.db to find probes for pathways (in hgu95av2PATH2PROBE). In order
> to find names out of these KEGG identifiers, I use KEGG.db. However,
> KEGG.db is deprecated starting bioconductor 3.13 and bioconductor officials
> suggest to use KEGGREST instead. Unfortunatly, KEGGREST seems not to find
> information from these microarray annotation package IDs. E.g.:
>
> library(hgu95av2.db)
> library(KEGG.db)
> library(KEGGREST)
>
> path.id <- ls(hgu95av2PATH2PROBE)[1]
> kegg.name <- KEGGPATHID2NAME[[path.id]]
> print(kegg.name)
>
> keggrest.info <- keggGet(path.id)
> print(keggrest.info)
>
> Does anybody have an idea, how to solve this?
>
> Cheers and thanks,
> Claudio
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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

Re: [Bioc-devel] Warnings about man pages for assignment operators on Windows builds

[Vincent Carey]

Hi Stephanie

I see similar problems for GenomicFiles, so it is not a problem unique to
your package.
I was not able to generate this error with r79717 in Windows 10, so I
conjecture that this
will go away when the R-devel for windows is upgraded.

Best regards
Vince

On Tue, Dec 29, 2020 at 1:58 PM Stephanie Gogarten  wrote:

> Hi all,
>
> Several of my packages have a set of warnings on the Windows devel builds
> that have persisted for a while now, all of this form:
>
> Rd warning: cannot open file
>
> 'C:/Users/biocbuild/bbs-3.13-bioc/meat/SeqVarTools.buildbin-libdir/00LOCK-SeqVarTools/00new/SeqVarTools/help/lastFilter<-.html':
> Invalid argument
>
> I have the following in my .Rd file:
>
> \alias{lastFilter<-}
> \alias{lastFilter<-,SeqVarIterator,numeric-method}
>
> Is there a different way I should be documenting assignment operators in
> R-devel?
>
> thanks,
> Stephanie
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

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