FWIW BiocManager::install() really delegates to install.packages(). The
packages are downloaded to 'destdir=' as documented on ?install.packages --
typically file.path(tempdir(), "downloaded_packages") -- and one path to
troubleshooting installs is to tackle the problematic installation(s) using
`install.packages(pkgs_in_downloaded_packages, repos = NULL)`, where
pkgs_in_downloaded_packages are the packages that have failed to install on
first pass.
It does seem like this would be a reasonable feature for base R, that we
could inherit, so one could ask on R-devel or submit a bug report / feature
request (e.g., via `bug.report()`).
Martin
?On 11/4/20, 1:19 PM, "Bioc-devel on behalf of Vincent Carey" <
bioc-devel-bounces at r-project.org on behalf of stvjc at channing.harvard.edu>
wrote:
I certainly have run into this situation with R generally. It seems
like a
patch to
install.packages would be the best approach to introduce this
functionality. I wonder
if Henrik Bengtsson or Dirk Eddelbuettel have pondered this.
In any case, I am sympathetic with the suggestion but I believe this
has to
be done
and tested outside the core developer team -- resources are too scant,
and
the
event of concern seems relatively rare. But maybe I overestimate the
burden.
On Wed, Nov 4, 2020 at 12:19 PM Keith Hughitt <keith.hughitt at gmail.com
> Sometimes I will go to update a machine / do a clean Bioconductor
> and a large number of packages will need to be downloaded.
>
> If something goes wrong during the installation, which is not
> cases where the number of packages being installed is large, then the
> process has to be restarted and the packages re-downloaded all-over
>
> Often, it may take some trial-and-error to fix the problem
> install from completing, the result of which is that you may end up
> re-downloading 50+ packages several times.
>
> Would it perhaps make sense for BiocManager to download
> to somewhere like "~/.cache/bioc/pkg" so that they could be re-used
> future installs?
>
> Obviously, it would be good for BiocManger to have some ability to
> old packages for removal (e.g. outdated/haven't been used in a long
> to avoid filling up people's hard-drives.
>
> Another possibility would be to build on top of the work done by
> which already has a very nice caching system.
>
> In any case, it seems like it would be something (relatively)
> straight-forward to implement that would save a lot of bandwidth and
--
The information in this e-mail is intended only for the
...{{dropped:18}}