[wix-devs] 5125 - Force cache if already present

[Sean Hall]

We discussed this at length in
https://www.firegiant.com/blog/2021/3/18/wix-online-meeting-208-highlights/
(starts at 34:15).  We discussed adding a cache request state to
OnPlanPackageBegin with the available options mirroring the options for the
Cache attribute (no/yes/always -> remove/keep/force).

In OnPlanPackageBegin, the BA can change the request state of the package.
The bundle author can influence the default request state with the
InstallCondition.

I think that the bundle author should have a similar ability to influence
the default cache request state. For example, they might want to have a
variable like LITEBUNDLE that they use to determine whether to keep
packages in the cache. Similarly, a different person might want
a HEAVYBUNDLE variable to determine whether to force cache everything.
Because there are three options, these can't be done by a simple condition
attribute. With this in mind, does it make more sense why I was trying to
push to separate "remove" from "force"? Does this change how you think it
should be exposed in OnPlanPackageBegin, or would there just be this weird
inconsistency where there would be multiple condition attributes for Cache?

On Sun, Mar 14, 2021 at 1:29 PM Sean Hall <r.sean.hall at gmail.com> wrote:

> https://github.com/wixtoolset/issues/issues/5125
> https://www.firegiant.com/blog/2015/12/18/wix-online-meeting-92-highlights/
> (starts at 6:00)
>
> The implementation of #5125 is pretty straightforward - force the package
> to be cached if the request state > BOOTSTRAPPER_REQUEST_STATE_ABSENT.
>
> As part of the work I did for #6297 in v4, I changed the implementation of
> Cache="always" (https://github.com/wixtoolset/issues/issues/4329) to rely
> on the request state of the package so that the BA could opt out of caching
> a package. What I've come to realize is that as described in #5125, there
> are cases where the engine will not cache the package even though the
> package was requested as present. And contrary to what was said in the
> meeting (and transcribed into the meeting notes), there has never been a
> way for the BA to request that a package be cached even though there are no
> actions for the package in the plan. So I think we need to add a
> fForceCache parameter to OnPlanPackageBegin that exposes the force cache
> functionality so the BA has a way to override it.
>
> I'm not sure how the functionality for #5125 should be exposed. There are
> really two separate concepts currently in the Cache attribute - whether the
> package should be kept in the cache and when to cache the package. People
> continue to be confused about what Cache="no" means, so maybe we should
> split it up like I originally did in the first implementation of #4329.
> Here are some ideas:
>
> 1. Cache can be no, yes, ifPresent (#5125), always.
> 2. Cache can be transient or alwaysClean ("no"), default or lazy ("yes"),
> eager or proactive (#5125), always.
> 3. Change Cache="no" to CleanCache="always", default is
> CleanCache="default". Change Cache="yes" to Cache="default", keep "always",
> add new one for #5125.
>
> Some other names that were proposed: forRepair, repair, stage, ifUseable,
> please.
>
>