Local installs vs. GH dependencies

[gaborcsardi]

Currently if a dependency is from GH via Remotes (or any way, really?), and there is a locally installed package, pak will always update that package from GH. I think this is because

1. It is hard to say what the user really wants, and after all the user said they wanted that package from GH.
2. It is not possible to determine the relationship between the installed package and the package in the GH repo.

Which all makes sense to me, but it also makes local development cumbersome when you are working on two packages locally and one depends on the other one.

This also happens in Positron, which uses local_install*() (?).

Btw. this is not unique to github::, but applies to all other remote types (git, gitlab, url, etc. possibly even standard, cran, bioc.)

[jennybc]

To answer a question from above, positron's "Install R package" gesture (aimed at local package dev work) is currently wired up to pak::local_install(upgrade = FALSE):

https://github.com/posit-dev/positron/blob/f6c0c1b159f2e7f937e339af634068d7a347a4cc/extensions/positron-r/src/tasks.ts#L48-L49

Personally, I am very pro pak for positron-r, but note there is an issue about switching away from it (which I don't really agree with or, at least, I'd prefer a solution that was more about allowing a choice):

https://github.com/posit-dev/positron/issues/2955

So I'd love to see these sorts of changes, which make it easier to advocate for pak as a default inside positron-r.

[gaborcsardi]

Maybe switching to R CMD INSTALL is the right choice here for Positron. I am not sure why pak is better here. The usual reasons possibly do not apply here:

• installing system packages on Linux is probably not very important, because if you are developing a package that needs some, the you probably already installed them
• installing R dependencies probably does not matter that much, either, for similar reasons.

[jennybc]

I disagree re: dependencies. In fact, that behaviour is very much how we ended up using pak in Positron:

https://github.com/posit-dev/positron/issues/1631

https://github.com/posit-dev/positron/issues/1732

[jennybc]

Hopefully I'm not conflating things, but this aspect of pak is what I find super useful and AFAIK not achievable in any other way:

upgrade

When FALSE, the default, pak does the minimum amount of work to give you the latest version(s) of pkg. It will only upgrade dependent packages if pkg, or one of their dependencies explicitly require a higher version than what you currently have. It will also prefer a binary package over to source package, even it the binary package is older.

When upgrade = TRUE, pak will ensure that you have the latest version(s) of pkg and all their dependencies.