pkgr
pkgr copied to clipboard
only download packages if needed to install
Currently, downloads all packages, regardless if need to be installed.
This would likely require a rearchitecture of the current implementation, in which the steps (get packages needed, dl all, install) would need to change some coordination logic. Namely, each is reasonably unaware of the global context. Instead, most "logic" is pushed down to the install step, in which during the attempt to install, it does the checking if its already installed, if a binary is available, etc.
Overall, this should be tackled more holistically in the installation planning stage
Acceptance Criteria:
- pkgr install downloads packages iff:
- The package is going to be installed OR the package is going to be updated.
Marking as "high-risk" because any re-architecting carries with it the ability to fundamentally break the code in new ways that may be hidden from us until after release. This could also possibly break tests (as in the tests will no longer be valid), which would extend development time.
Mitigating the high risk with more rigorous testing would likely turn this into high-effort.
one way we could handle this is to break from how R does it (download all deps first, then start to install), and instead in the install loop, if and only if a package gets requested to install, first go download it. The other benefit this would have is time to first install would be shorter, especially for large amounts of downloads, as sometimes it can be a couple minutes of just downloading packages, especially on slow connections, before the first packages start to install.
I agree that this is a good approach, as it addresses issues that we'll probably want to take care of later was well. If we go this route, I think we should bump this up to high-effort.
My first pass at a solution (#139) involved basically just removing installed packages from the installPlan. There's a lot of room for improvement there, and a few edge cases we'd want to test (e.g. what if we remove an entire "layer" of dependencies in the middle of the dependency tree?), but it doesn't require us to rearchitect too much, so I also think this is a valid approach.
I think rearchitecting earlier is always better than rearchitecting later, so I'm in favor of biting the bullet and doing it, it'll just take longer. Let me know what you think.