Feature request: Automatically install from source when no binaries are available, including dependencies

[billdenney]

Related to #252

I just tried to install cmdstanr in Windows with R 4.1. It comes from a drat repository where there is no R 4.1 binary built (yet), but the source is available. There are also required dependencies in the same drat repo that do not yet have binaries built for Windows with R 4.1 (my immediate note is posterior, but as I work through this, there will probably be others).

My request is:

1. Allow automatic installation from source, with a command line flag (my preference would be for that to default to installing from source if no binary is found, but no worries either way there); this element is a small extension of Alert user more clearly if no binary is available, but source is available, for a specific package #252
2. For dependencies of a package that is installed from source, automatically first search for binaries and then for source.

My pkgr.yml is here: pkgr.txt

This will probably no longer be a reproducible issue when they start building the drat repo for R 4.1, but the idea will hold. (And, it could be reproduced by forking the cmdstanrrepo and deleting the 4.1 binary directory, when they do start.)

[billdenney]

The workaround is here (the difference is the customization to install posterior from source):
pkgr.txt

[dpastoor]

the biggest concern I have with this, which maybe shouldn't be part of pkgr's responsibility, is the goal around being as declarative as possible and consistent as possible. So, for example, given a platform with binary as a default, calling out the need to compile for source.

That said, the original philosophy really hasn't held as strongly as I thought pkgr might one day need to go. Between renv + the use of things like MPN/rstudio package manager, it might be time to loosen that assumption.

Realistically it would also make our internal lives easier as all our CI pipelines spit out cran-like repos...but they only have source versions, so that same either repository level customization or package level customization is consistently needed.

This is good timing to bring this up as I'm hitting on some pkgr dev. I think this may be feasible without not a lot of effort, but the devil will be in the details.

Essentially would need to teach pkgr's upfront planning more about introspecting binary vs source.

Laying out the logic it would basically be:

1. check if binary url available. This currently fails and moves on now, but could adjust to if does fail, change the packaging behavior to force source for all packages in that repo

That actually would be a pretty easy hit, for drat/cranlike repos that just straight are missing any binaries (which I think is your case, and is definitely our case). But then the secondary need around partial repos where some binaries are missing would need to know which packages came from that repo, check if binary, if not then fall back to source.

I have been waivering on implementing 1, which i think this issue will tip me over the edge to pull that trigger. The second part I need to poke around a little.

[billdenney]

I think that if the behavior became the following, it would likely keep close to the declarative design choice while making it simpler when the declarative choice is not available:

Add a new "Type" option for package type so that the three options would be auto, binary, or source with auto being the default.

1. Check if there is a Type customization selection for binary/source.
   1. If no Type customization, set to the default (auto, likely configurable by a global setting in the .yml file).
2. Search for the package:
   1. If Type is auto or binary, search for a binary package.
      1. If the binary package is found, install it and move on to the next package.
      2. If the binary package is not found and Type is binary, error with a message telling the user about auto or source (as suggested in Alert user more clearly if no binary is available, but source is available, for a specific package #252).
      3. If the binary package is not found and Type is auto, proceed to try to find a source package.
   2. If Type is source or you are continuing from 2.i.c., search for a source package.
      1. If the source package is found, install it and move on to the next package.
      2. If the source package is not found, error with a message.