Update 2 dependencies

[mtrmac]

github.com/santhosh-tekuri/jsonschema/v5 is about 2 years old, github.com/russross/blackfriday more than 4 years old. Keeping up will only get harder as the users stay behind.

Note a possible downside: The v6 of the JSON schema parser imports golang.org/x/text to support localized error messages, and that is +17570 of a dependency.

Warning: I am not an expert in either of the packages, I was looking for the most similar new APIs. (I did manually verify that the markdown parsing produces the same code examples.)

[tianon]

As we just discussed in the OCI weekly meeting, Go version updates always make me nervous, especially with how many people import github.com/opencontainers/image-spec just for our struct/const definitions (which have essentially no Go version requirement and probably work all the way back to like Go 1.0 or earlier).

One idea we discussed was perhaps moving these deps/constraints to a new go.mod under schema (ie, create schema/go.mod) -- this would effectively create a new github.com/opencontainers/image-spec/schema "module", but the imports would all be exactly the same and go mod tidy should just DTRT for fixing consumers. 🤔

(Doing that would resolve my concerns pretty well, since the schema validation code has more valid reasons for enforcing a specific Go version than the struct/const definitions do.)

[mtrmac]

For a preview, this is what splitting out a …/schema module would look like.

Note the process in https://go.dev/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository : the next release of this repository would have to add tags, and a new inter-module dependency. I couldn’t test all of that directly, that would remain a lingering disk for the next release.

[mtrmac]

This part is TBD.

[sudo-bmitch]

I think a lot of the issues you're encountering would be solved with a go.work file. That shouldn't be committed to the repo, but can be setup in the GHA so that the CI jobs are running the tests against a consistent state.

[sudo-bmitch]

Lets revert this back to the original values. The go.mod file used can be changed in the setup-go step. In the render and lint step, initialize the go.work file.

[sudo-bmitch]

I don't think this is needed. The tag at the top level will apply to the whole repo. The only issue with that is the schema/go.mod needs to refer to the version of the image-spec. Tagging that spec sets a hash, that hash needs to be in the go.sum, and that file needs to be part of the tagged content, so there's a circular dependency. We might want to solve that by pinning to a preceding commit rather than the tagged release.

[sudo-bmitch]

Replace should only be used in development, and in this scenario, I think a go.work is a better solution. To implement:

cd ..
go work init
go work use .
go work use schema

[sudo-bmitch]

Note that the go.work file should not be checked into the repo, so it would be added to the .gitignore, and the beginning of the GHA jobs can recreate it.