google/deps.dev

Serve "observed at" times for Go modules

ThomasJanUta opened this issue · 1 comments

ThomasJanUta commented

"Published" is empty for GO package versions on the website https://deps.dev/go/github.com%2Frs%2Fzerolog/v1.31.0/versions :
image

Same for the REST API:
NPM: https://api.deps.dev/v3alpha/systems/npm/packages/typescript
image

GO: https://api.deps.dev/v3alpha/systems/go/packages/github.com%2Frs%2Fzerolog
image

I checked all systems and GO and NUGET seem to be incomplete? The REST API documentation does not mention why some attributes are missing in these systems.

available: versions + published_at + dependents

CARGO https://deps.dev/cargo/rand/0.8.5/versions
NPM https://deps.dev/npm/react/18.2.0/versions
PYPI https://deps.dev/pypi/beautifulsoup4/4.12.2/versions
MAVEN https://deps.dev/maven/org.springframework%3Aspring-core/6.1.1/versions

available: versions + dependents

GO https://deps.dev/go/github.com%2Frs%2Fzerolog/v1.31.0/versions

available: versions + published_at

NUGET https://deps.dev/nuget/hangfire.core/1.8.6

Is it possible to add the published timestamp?

The underlying source https://index.golang.org/index has timestamp so I am wondering why that aren't available on deps.dev. I need this information to be available in my project to be able to build package timelines.

adg commented

There's a good technical reason why we don't serve published_at for Go packages/modules:

The Timestamp values provided by https://index.golang.org/index are "the time it was first cached by proxy.golang.org" (source), not the actual time the module version was published. Since module versions are published typically by updating a Git branch HEAD, and there is no reliable way to know when a Git branch changes, we don't know the actual time when a module version was published.

The best we can do is offer the time at which we first observed the version or the time when the module proxy says it first observed it (whichever is earlier, often our infra finds new module versions before the proxy does). We do have this data in our system, but plumbing it through to the API and making sure the values are correct will take a bit of effort, so it's not something we can do immediately.

I'll label this as a feature request, and change the title a bit. Thanks so much for the feedback.

  • 👍1