Ok, after digging into this, I don't believe this is a viable solution.

indirect dependencies listed in go.mod are based on dependencies of dependencies. To find out why this indirect dependency exists, you can run:

go mod why github.com/myesui/uuid

and note that it originates from the Revel session id code which depends on another uuid package that depends on the missing package:

# github.com/myesui/uuid
github.com/revel/cmd/model
github.com/revel/cmd/model.test
github.com/revel/revel
github.com/revel/revel/session
github.com/twinj/uuid
github.com/twinj/uuid.test
github.com/myesui/uuid

So, the best solution would more likely be to use a package that is less likely to move in the future like github.com/google/uuid (minor revel session code refactor) or to vendor the dependency (we've done this for some time by forking repos to the revel github organization.

Thank you @mjoork for this effort. I will try to get this addressed along with some other breaking issues.

A quick follow up note, because I wanted to make certain my findings were accurate. github.com/twinj/uuid@v1.0.0 refers to the old myesui/uuid which is cached on pkg.go.dev, but has no go.mod and therefore no matching v1.0.0 version tag.

Without knowing the whole truth, it seems myesui was renamed to bakanis as that is where the twinj repo is forked from. The user, twinj, likely tried to get their own dependent code working with a newer version of go that supported modules. Twinj likely overlooked the test file reference to a non-existent repo (which may have existed at the time that twinj created their fork's v1.0.0 tag).

Anyway, revel needs to vendor this dependency or use a more stable repo.

Yes, I initially also found exactly that. I didn't know of a better fix. Glad to see this getting fixed in the future. Thank you for the detailed information!