It is wrong to say that ‘it will never be solved for R.4.0.0’. Rather, ‘it will 
never be a problem for R.4.0.0’.

rtracklayer 1.51.5 was only ever built, checked, distributed (and installed in 
a correctly configured system, using the rules of install.packages and 
tools:::.BioC_version_associated_with_R_version(), or of 
BiocManager::install()) on R-devel (now R-4-1-0-branch). So R-4.0.* has never 
supported version 1.51.5 of rtracklayer.

No Bioconductor package built on R-4.0.* would propagate (be visible to 
install.packages()) with a dependency on rtracklayer-1.51.5. A CRAN package 
with a dependency on rtracklayer-1.51.5 (this is hypothetical, I do not believe 
it is the case for CNVScope), would be correctly flagged as an error – this 
version of rtracklayer will never be available on R-4.0.*, and the CRAN package 
author would have to re-assess the reasons for specifying the dependency for 
that version of R.

Bioconductor does rarely produce ‘impossible’ dependencies particularly in the 
Bioconductor ‘devel’ branch (when a package builds and checks even though one 
of its dependencies builds but does not pass check), but these are transient 
and an artifact of the Bioconductor  build system – the lagging package Is 
usually promptly updated so the published dependency is satisfied.


From: Henrik Bengtsson <henrik.bengts...@gmail.com>
Date: Tuesday, May 18, 2021 at 2:41 PM
To: Martin Morgan <mtmorgan.b...@gmail.com>
Cc: "Dalgleish, James (NIH/NCI) [F]" <james.dalgle...@nih.gov>, 
"r-package-devel@r-project.org" <r-package-devel@r-project.org>
Subject: Re: [R-pkg-devel] Old version of rtracklayer on a single check server

I stand corrected about the R-devel version (and now R 4.1.0) on CRAN.

However, isn't it the case that it will never be solved for R 4.0.0 (to become 
R-oldrel on CRAN) and CRAN will keep reporting an error on MS Windows there 
because https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html 
provides only an older version for MS Windows?

If so, an alternative to relying on Suggests is to make the package depend on R 
(>= 4.1.0).

/Henrik

On Tue, May 18, 2021, 09:08 Martin Morgan 
<mtmorgan.b...@gmail.com<mailto:mtmorgan.b...@gmail.com>> wrote:
That’s not correct Henrik.

CRAN follows CRAN rules for installing packages, so uses 
tools:::BioC_version_for_R_version(). For R-devel we have

> R.version.string
[1] "R Under development (unstable) (2021-05-18 r80323)"
> tools:::.BioC_version_associated_with_R_version()
[1] '3.13'

For this version of Bioconductor, the rtracklayer version (from 
https://bioconductor.org/packages/3.13/rtracklayer, or 
`available.packages(repos = 
"https://bioconductor.org/packages/3.13/bioc";)["rtracklayer", "Version"]`) is 
1.51.5.

So the r-devel-windows-ix86+x86_64 builder mentioned in the post has the wrong 
version of rtracklayer for R-devel.

Martin Morgan

On 5/18/21, 11:49 AM, "R-package-devel on behalf of Henrik Bengtsson" 
<r-package-devel-boun...@r-project.org<mailto:r-package-devel-boun...@r-project.org>
 on behalf of henrik.bengts...@gmail.com<mailto:henrik.bengts...@gmail.com>> 
wrote:

    It's a problem with Bioconductor and a broken release history of
    'rtracklayer' on MS Windows (e.g.
    https://bioconductor.org/packages/3.12/bioc/html/rtracklayer.html)
    plus how each Bioconductor version is tied to a specific R version.
    In other words, even if they fix it in Bioconductor 3.13 (for R
    4.1.0), it can't be fixed in Bioconductor 3.12 (for R 4.0.0), so
    you're package will keep failing on Windows for R 4.0.0.  The reason
    why it can't be fixed in Bioconductor 3.12 is that they have now
    frozen that release forever.

    Because of this, I suspect the only solution is to make 'rtracklayer'
    an optional package, i.e. move it to Suggests: and update all your
    code to run conditionally of that package being available. I recommend
    you reach out to the bioc-devel mailing list for advice.

    /Henrik

    On Tue, May 18, 2021 at 4:33 AM Dalgleish, James (NIH/NCI) [F] via
    R-package-devel 
<r-package-devel@r-project.org<mailto:r-package-devel@r-project.org>> wrote:
    >
    > To any who might have an idea:
    >
    > I've been reading several posts in the digest about dependency version 
issues on the check servers and I'm having my own issue, which I can't solve 
because I can't upgrade the check server's package version:
    > * installing *source* package 'CNVScope' ...
    > ** using staged installation
    > ** R
    > ** data
    > *** moving datasets to lazyload DB
    > ** inst
    > ** byte-compile and prepare package for lazy loading
    > Warning: multiple methods tables found for 'export'
    > Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), 
versionCheck = vI[[j]]) :
    >   namespace 'rtracklayer' 1.48.0 is already loaded, but >= 1.51.5 is 
required
    > Calls: <Anonymous> ... namespaceImportFrom -> asNamespace -> loadNamespace
    > Execution halted
    > ERROR: lazy loading failed for package 'CNVScope'
    > * removing 'd:/RCompile/CRANguest/R-devel/lib/CNVScope'
    >
    > These errors tend to be check server dependent (only occurs on 
r-devel-windows-ix86+x86_64<https://cran.r-project.org/web/checks/check_flavors.html#r-devel-windows-ix86_x86_64>)
 and I'm just trying to make the small change to closeAllConnections() that was 
asked earlier of maintainers by Kurt Hornik and the CRAN team, but I can't 
because of this old package version on the devel check server, which has the 
same error:
    > 
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00check.log
    > 
https://win-builder.r-project.org/incoming_pretest/CNVScope_3.5.7_20210518_062953/Windows/00install.out
    >
    > Is there any way around this? I notice the maintainer of the 'gtsummary' 
package had a similar issue:
    >
    > "> I am trying to make a release that depends on gt v0.3.0, but I get an 
error
    >
    > > when I test the package on Windows Dev `devtools::check_win_devel()` 
that
    >
    > > the gt package is available but it's an unsuitable version.  Does anyone
    >
    > > know why the gt v0.3.0 is unavailable?"
    >
    >
    >
    > I'm open to any suggestions, but can't see a way around this issue from 
my end without the ability to service the check server.
    >
    >
    > Thanks,
    > James Dalgleish
    > Cancer Genetics Branch,
    > Center for Cancer Research,
    > National Cancer Institute,
    > National Institutes of Health,
    > Bethesda, MD
    >
    >
    >         [[alternative HTML version deleted]]
    >
    > ______________________________________________
    > R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> 
mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-package-devel

    ______________________________________________
    R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing 
list
    https://stat.ethz.ch/mailman/listinfo/r-package-devel

        [[alternative HTML version deleted]]

______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to