You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since it was requested in Mill's chat room, here is some input regarding Mill's cache. I have to admit, I didn't review the full PR and all comments, but from what I digested, here are my notes:
If you return a PathRef that points to somewhere outside of Mill's cache, there is a chance Mill will miss it's later invalidation due to removal or change. Therefore in Mill 0.11 we introduced the revalidate flag which you can enable with PathRef.withRevalidateOnce. When enabled and before re-using a targets cache, Mill will re-calculate the PathRef.sig and will only use the cached value if the sig is still identical. I think you should use this flag since you don't have exclusive control over the output directory.
Using an T.input or a PathRef in general for a path you intend to change from a downstream target, will most likely cause unnecessary re-evaluation. Since you intend to generate something into that path, it's sig will change. If you're not interested in the content of a path, which is the case for config values, the path itself should be enough.
Relates to #1499 and this discussion: #1499 (comment)
Since it was requested in Mill's chat room, here is some input regarding Mill's cache. I have to admit, I didn't review the full PR and all comments, but from what I digested, here are my notes:
If you return a
PathRef
that points to somewhere outside of Mill's cache, there is a chance Mill will miss it's later invalidation due to removal or change. Therefore in Mill 0.11 we introduced therevalidate
flag which you can enable withPathRef.withRevalidateOnce
. When enabled and before re-using a targets cache, Mill will re-calculate thePathRef.sig
and will only use the cached value if thesig
is still identical. I think you should use this flag since you don't have exclusive control over the output directory.Using an
T.input
or aPathRef
in general for a path you intend to change from a downstream target, will most likely cause unnecessary re-evaluation. Since you intend to generate something into that path, it'ssig
will change. If you're not interested in the content of a path, which is the case for config values, the path itself should be enough.Originally posted by
@lefou
in #1499 (comment)The text was updated successfully, but these errors were encountered: