Make contents.plist optional

[justvanrossum]

I felt some consensus in the meeting that we should make contents.plist optional. I think it may even be considered for UFO 3.1.

Related to #114.

[alerque]

While I agree this would be a step in the right direction, discretionary elements of a format spec always end up being pain points. Who would benefit from the spec having this optional list rather than just leaving any tooling that needs it to build their own cache in whatever serialized format is expedient using whatever update trigger they want without worrying about who else is using the data and may be affected? If the file is optional and exists, do you have to rescan the directory anyway or just blindly trust that whatever tooling created it also kept it up to date?

I can see the utility of such a list for some tooling, but what does the UFO ecosystem gain from having it as a complex 'maybe' (maybe it's there, maybe you can trust it) element at all? If it's optional then SPEC compliant tooling must function without it, so we're not leaving a shortcut of 'optionally' not bothering with being able to scan the directory to regenerate the info in memory/cache.

At most maybe specify a 'cache' directory or similar where tooling can put things like this with an explicit note that it should not be included in VCS or any other import/exports/transfers. At which point just letting tooling keep that info wherever it's other temporary cache data is would be more beneficial.

Perhaps this should actually be transitioned to a lib key ala #118 — with a formalized mini-spec based on the old (current) UFO behavior that would be an logical transition for exciting tooling (although they would still need to recode the implementation to not trust it as canonical).

[belluzj]

Example related issue in tooling: source-foundry/ufolint#77

[frankrolf]

Here is a real-world example why making contents.plist optional would be great:
adobe-fonts/source-serif@b5a33a6