Martin, Dirk, Kevin,
Thanks for your help. To summarise: the order of access is undefined, and
every repo URL is accessed. I'm working in an environment
where "known-good" is more important than "latest", so what follows is an
explanation of the problem space from my perspective.
What I am expe
It may also be useful to use:
options(internet.info = 1)
to get more information on the web requests R is making. (See the
documentation in ?options for more details.)
Looking at the source code in available.packages, R does iterate
through the repositories in the same order they're provided
On 31 March 2024 at 11:43, Martin Morgan wrote:
| So all repositories are consulted and then the result filtered to contain just
| the most recent version of each. Does it matter then what order the
| repositories are visited?
Right. I fall for that too often, as I did here. The order matters f
available.packages indicates that
By default, the return value includes only packages whose version
and OS requirements are met by the running version of R, and only
gives information on the latest versions of packages.
So all repositories are consulted and then the result filtered
Dirk,
Sadly I can't use localhost for all of those. 172.17.0.1 is an internal
Docker IP, not the localhost address (127.0.0.1), they are there to handle
two different scenarios and different ones will fail to resolve in
different scenarios. Are you saying that the DNS lookup adds a timing
issue t
Greg,
There are AFAICT two issues here: how R unrolls the named vector that is the
'repos' element in the list 'options', and how your computer resolves DNS for
localhost vs 172.17.0.1. I would try something like
options(repos = c(CRAN = "http://localhost:3001/proxy";,
When I set multiple repositories in options(repos=...) the order of access
is providing me with some surprises as I work through some CICD issues:
Given:
options(
repos = c(
CRAN = "http://localhost:3001/proxy";,
C = "http://172.17.0.1:3002";,
B = "http://172.17.0.1:3001/proxy";
