Add strict option

[teatimeguest]

See #329. @muzimuzhi

[muzimuzhi]

With what we already have

In v3.3.4, cache is also updated when a package is updated. This is also the case when tlmgr itself is updated with update-all-packages: false.
_{#329 (comment)}

setting strict: true won't change the cache update behavior, but only make the new cache use new cache key (and perhaps differs in whether the old cache is removed)?

[teatimeguest]

If update-all-package: true, then yes. But if not,

This also seems not ideal. As scheme and collection names are both accepted, when a new package is added to a scheme or collection, then it will never be installed when cache is hit? (#329 (comment))

this still remains.

Would the change in v3.3.4 be sufficient?

[muzimuzhi]

On rethinking, I now think it all depends on what the expected installation outcome is after a cache is restored.

1. With cache: false, all schemes/collections/packages are installed from scratch, thus all latest versions are installed.
2. With cache: true and when no cache is restored (due to no existing or no matching caches), it falls back to the first case.
3. With cache: true and when a cache is indeed restored,

• 3.1 if update-all-package: true is set, then the resulting installation is the same as previous cases;
• 3.2 if update-all-package: false is set (which is the default in v3.3.4), then the installation would finish with historic list of packages (ignoring auto-remove and auto-install ones, see doc of tlmgr update) and their historic versions.

Therefore it seems to me, update-all-package: true should be set by default.

(Lacking of lock file does change the installation staggery and complicate the situations...)

[teatimeguest]

Therefore it seems to me, update-all-package: true should be set by default.

I understand that this is ideal for package/class maintainers. But for book/paper authors,

3.2 if update-all-package: false is set (which is the default in v3.3.4), then the installation would finish with historic list of packages [...] and their historic versions.

I still think this is rather expected, more preferable behavior; It is just as packages are not updated in a local environment unless one consciously does tlmgr update.

In my experience, editorial processes and/or submission systems often require an older version of TeX Live. For example, if you look at the section "How do I identify which submission system I’m using?" in the FAQs on this page of Springer Nature, you will find that TeX Live 2017 is still in use. (This is the main reason why the action supports the installation of older versions.)

Rarely is the version to be used explicitly stated in such a way. Sometimes editors later complain that they cannot compile. Thus, in order to avoid problems, it is unfortunately an effective strategy to avoid updating packages and to avoid using new features as much as possible.

In such a situation, it would be more beneficial to be able to check the compiled results quickly than to have packages updated. This is my concern with defaulting to update.

[teatimeguest]

However, active development can keep a cache alive for an unintentionally long period of time without packages being updated. This can indeed be considered a problem.

I think a possible solution would be to update packages (and cache if appropriate) when the cache age exceeds a certain value (e.g., 7 days) even if update-all-packages: false. This would not prevent either quick cache restoration or regular package updates.

Please let me know if you have any thoughts on this.

[muzimuzhi]

For book/paper authors, maybe docker image is the best choice to get a version-locked full LaTeX installation (exceptions are the historic yearly versions of TeX Live). For example islandoftex provides weekly snapshots of TeX Live images.

Ideally the cache mechanism should be transparent to users. That is, whether a cache is restored or not should only affect the installation time, but not what will be installed. update-all-packages: false breaks this thus it becomes users' responsibility to be aware of cache restoration.

As caches without access will expire after 7 days, a rather short duration, I'm afraid update-all-packages: false won't always help.

[muzimuzhi]

I see what's the key of my concern: cache is far from a persistent storage which makes the behavior of setting update-all-packages: false not reliable. As a cache expires in 7 days and an artifact expires in at most 90 days, the only persistent storage is the release asset.

[pablgonz]

For book/paper authors, maybe docker image is the best choice to get a version-locked full LaTeX installation (exceptions are the historic yearly versions of TeX Live). For example islandoftex provides weekly snapshots of TeX Live images.

I understand the point, but you can get by with what is described in #289 (comment) on the other hand (from my perspective) running update-all-packages: false should do exactly what the key says, i.e. DO NOT UPDATE ANYTHING, no matter the amount of time (7 days or 90 days).

[muzimuzhi]

I understand the point, but you can get by with what is described in #289 (comment)

Great! I didn't know there are daily archives of texlive (or once read but then totally forgot it).

on the other hand (from my perspective) running update-all-packages: false should do exactly what the key says, i.e. DO NOT UPDATE ANYTHING, no matter the amount of time (7 days or 90 days).

@pablgonz Sounds like a complain about bad naming :), as it has been documented as "Update all TeX packages when cache restored." from day one (see 029f57a).