[R-pkg-devel] Old version of rtracklayer on a single check server

Dalgleish, James (NIH/NCI) [F] j@me@@d@|g|e|@h @end|ng |rom n|h@gov
Thu May 20 06:20:38 CEST 2021


Thanks to Martin and Henrik for an in-depth discussion that really helped me quite a bit.

Requiring R-4.1.0 made it CRAN compliant and stopped the installation issues on both check servers.

Considering the number of packages that use rtracklayer (it’s one of the most used packages on Bioconductor), this will help a lot of users as well.

Thanks again!

Best,
James Dalgleish
From: Martin Morgan <mtmorgan.bioc using gmail.com>
Sent: Tuesday, May 18, 2021 3:34 PM
To: Henrik Bengtsson <henrik.bengtsson using gmail.com>
Cc: Dalgleish, James (NIH/NCI) [F] <james.dalgleish using nih.gov>; r-package-devel using r-project.org
Subject: Re: [R-pkg-devel] Old version of rtracklayer on a single check server

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.bengtsson using gmail.com<mailto:henrik.bengtsson using gmail.com>>
Date: Tuesday, May 18, 2021 at 2:41 PM
To: Martin Morgan <mtmorgan.bioc using gmail.com<mailto:mtmorgan.bioc using gmail.com>>
Cc: "Dalgleish, James (NIH/NCI) [F]" <james.dalgleish using nih.gov<mailto:james.dalgleish using nih.gov>>, "r-package-devel using r-project.org<mailto:r-package-devel using r-project.org>" <r-package-devel using r-project.org<mailto:r-package-devel using 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.bioc using gmail.com<mailto:mtmorgan.bioc using 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-bounces using r-project.org<mailto:r-package-devel-bounces using r-project.org> on behalf of henrik.bengtsson using gmail.com<mailto:henrik.bengtsson using 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 using r-project.org<mailto:r-package-devel using 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 using r-project.org<mailto:R-package-devel using r-project.org> mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

	[[alternative HTML version deleted]]



More information about the R-package-devel mailing list