[WIP] Support for @v/list and @latest endpoints in an offline environment #1676
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the problem I am trying to address?
I am using Athens to use go modules in an offline, air-gapped environment. With download mode set to none, the @v/list and @latest api endpoints are still trying to go out to the internet to retrieve version information.
How is the fix applied?
When download mode is set to none and disk storage is used, @v/list will list only the modules available on disk, and @latest will return the latest version from the modules available on disk. It will not try to go out to the internet, since nothing can be downloaded anyway with download mode set to none.
So far these changes are working perfectly in my environment. I am able to develop using go modules as if I was online with no workflow changes or workarounds.
TODO: the implementation of @latest (sorting all the versions) could probably be moved somewhere else and/or simplified.
For reference, I am using the following system to synchronize the disk storage between my online and offline networks:
go mod download
doesn't really work, because (as far as I can tell) outdated semver-compatible dependencies need to be found before the go module system can decide that they can be updated. For example: your package directly requires foo v1.0.2. A dependency of yours requires foo v1.0.1. When online, go finds v1.0.1, but also knows that v1.0.2 is available, and the dependency's foo is updated to v1.0.2 automatically since it's semver compatible. But when offline, go still needs to be able to locate v1.0.1, which means we need both versions in our Athens disk cache.go mod download
will only give you v1.0.2.This works and it's relatively easy. It would be nice to be able to configure Athens to serve the default download cache disk format instead of needing to re-structure the files. Maybe that could be a potential improvement for this PR.
Reference issue
Closes #1868