Allow source installation again

[lorenzwalthert]

trafficstars

Is your feature request related to a problem? Please describe.

Currently, only binary packages from PPM are supported for additional_dependencies. I would like to laxen the requirements upstream to allow attempting source installations. This was previously disabled, since in case the CRAN mirror has a younger version of the R package you want to depend on than your .pre-commit-config.yaml, you will try to install a source package, as only the up-to-date binary is kept in PPM. Since we use frozen snapshots, we will still be able to install a not-up-to-date binary, since for that URL, there won't ever be another one. Describe the solution you'd like

With the frozen URLs, I think we can allow source installations again, which should only affect packages that don't have a binary version: They now fail to install, in the future, a source installation should be attempted. In managed environments like pre-commit.ci, this might not work, but at least it will work locally and in CI environments the user controls.

Describe alternatives you've considered

Not use packages as dependencies that don't have a binary on PPM for all required operating systems. Request a binary.

[averissimo]

I believe there's another use case for source installation where there are no binary repositories.

I'm currently running Ubuntu Oracular (non-LTS) and I can't use precommit as it fails to install, both using the released version as well as your fork of pre-commit that allows for both binary and source.

I've changed that branch to have an override on the repo (renv.config.repos.override) and it works like a charm!

It's a shame that renv doesn't default to a source repo that is not under the architecture/distribution.

Thanks for this feature, albeit still experimental

[lorenzwalthert]

Thanks for letting me know gem know @averissimo. Seems like my upstream fork (of pre-commit, the python package) is not enough... Do you think there is a generic solution for the problem and where would it be implemented (pre-commit upstream framework vs R package or hook repo like {precommit})?

[averissimo]

Taking another look at it, your implementation of allowing both types of packages allows for enough flexibility using {renv}'s environmental variables to configure it.

As in, with this: export RENV_CONFIG_REPOS_OVERRIDE=https://cloud.r-project.org

Adding a footnote on the documentation reminding users that renv can be configured with env vars should cover any edge cases.

[lorenzwalthert]

Thanks for looking into it. So you recommend setting the env variable when installing the hooks with $ pre-commit install? Would that then install all packages from source and from that repo?

[averissimo]

Thanks for looking into it. So you recommend setting the env variable when installing the hooks with $ pre-commit install?

Yes, it gives a great deal of flexibility to achieve whatever the user wants. In my use case I can override the repo or just disable ppm binaries.

I'm doing this by changing the pre-commit python script to setup the variable, but I guess that would also work by setting the variables in .bashrc / .zshrc / .profile

Would that then install all packages from source and from that repo?

Yes, from latest CRAN using the option above, or from ppm source snapshot using a different variable (RENV_CONFIG_PPM_ENABLED)

I've tested both approaches successfully.

---

note: I can only test the all-pkgs source build, not the mixed binaries and source in my system.