[Bioc-devel] External software dependencies, bioc builders, and docs maintenance

[Spencer Nystrom]

Hi all,

Related to the recent discussion of packages building "fake" docs, I wanted
to call myself out here as being guilty of it and discuss how to mediate
the issue.

In my case, the {memes} package (
https://bioconductor.org/packages/release/bioc/html/memes.html) has core
functionality that depends on an external install of the meme suite family
of tools. This is currently missing on the builders, so there are a few
vignettes and examples that use a `NOT_CRAN` style check if the software is
missing at build time to skip those executions. In order to build more
useful docs, I render them with a github action using a container with the
software installed and post them to my own site, which I also point users
towards. I completely agree this is suboptimal, and it has haunted me for
some time now.

I see 3 potential solutions to the problem:

1. Install the latest Meme Suite version on bioc builders. Without
enumerating all the ways this could cause issues, I foresee mismatches
between the version I support vs installed on the builders could make this
a recurring maintenance burden for the core team.

2. Use {basilisk} to provide a conda env with the current supported MEME
Suite version within the {memes} package. This has its own issues because
the current conda envs for the MEME Suite don't really work right, and I'm
not sure I can take on the maintenance burden of something that extensive.
There have historically been a few cryptic bugs in their configs.

3. Some kind of {memes}-driven installer. I've seen other bioc packages
provide helper functions that install software for the user with their
permission & in a user-provided location. Provided the builders have the
system dependencies installed, I guess the package could install the
software to a tmpdir and clean up after itself on bioc builders. This also
seems pretty hacky and error prone from  a builder perspective.

Anyway, I'd appreciate any feedback here. In the course of writing this
I've talked myself into doing another round of due diligence with the conda
versions but curious to hear others thoughts. In particular this pattern of
relying on an external dependency is one I've seen a few times in other
packages and have seen it solved in a variety of creative ways.

Best,
  -Spencer

	[[alternative HTML version deleted]]