pkgr icon indicating copy to clipboard operation
pkgr copied to clipboard

only download packages if needed to install

Open dpastoor opened this issue 6 years ago • 5 comments

Currently, downloads all packages, regardless if need to be installed.

dpastoor avatar Dec 10 '18 18:12 dpastoor

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

dpastoor avatar Feb 24 '19 19:02 dpastoor

Acceptance Criteria:

  • pkgr install downloads packages iff:
    • The package is going to be installed OR the package is going to be updated.

Dreznel avatar Aug 01 '19 13:08 Dreznel

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.

Dreznel avatar Aug 01 '19 13:08 Dreznel

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.

dpastoor avatar Aug 02 '19 01:08 dpastoor

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.

Dreznel avatar Aug 02 '19 19:08 Dreznel