For Bazel String flags, is there a recommended way to use the string flag without discarding analysis cache?

[Ryang20718]

For Bazel String flags, is there a recommended way to use the string flag without discarding analysis cache?

[fmeum]

@gregestren Is preserving the analysis cache across changes to Starlark flags only something you would consider doable? This could be an interesting sweet spot for improvements in this area.

[gregestren]

Ideas here always welcome. I'd love to restrict the effect as much as we can do safely.

[fmeum]

Could we model Starlark flags as first-class Skyframe nodes rather than entries in a single Map so that change pruning could take care of this rather than us having to remember to drop the cache in certain cases? I can see how this would be a major undertaking, but are there any conceptual blockers to it?

[gregestren]

Interesting idea. I'm not totally sure it pans out but I like the thought. I'll give this some more thought.

[gregestren]

Starlark flags are of course also rules that consumers depend on to extract their values. I thought (but can't remember) that implied a Skyframe edge from each consuming configured target to the Starlark flags it reads. I think select() resolution would have similar effect.

Unless I'm misremembering and we had distinct logic that executed the Starlark rule implementations and stored the results in a map.

If the above is true, I think we could adjust the logic to only invalidate Starlark flag rules themselves when their command-line values change. Which is much closer to optimal.

[gregestren]

For what it's worth, we have another initiative in the works related to skyfocus that might help this a lot.