Implicit runtime dependencies (with examples from core/go)

Core Development Core Plans
1

Hi,

I am putting together a patch for our core/go plan and have stubled into a problem that is part practical and part philosophical. Here is the problem:

The go standard library has hard-coded paths to zoneinfo data. Those paths are incorrect on our minimal Habitat hosts:

This is easy enough to fix via a small patch, and the core/go plan already has examples where we patch in paths to files contained in habitat packages:

However, both my proposed fix for zoneinfo and the existing patch for cacerts have a problem. Namely, any app that is built with core/go now, technically, has an undeclared runtime dependency on core/cacerts (or core/zoneinfo or core/iana-etc). Any go application that fails to explicitly declare this dependency may fail at runtime.

Declaring the dependency is straightforward once you know it is there, but right now we don’t have anything that alerts the user to this situation. Thoughts?

Cheers,

Steven

2

Can we not just declare these dependencies in core/go to fix this?

Edit: No, because core/go is a build dep, not a runtime dep. Got it… Hmm!

3

This smells like a missing type of dependency. Like we need a way for core/go to say it needs zoneinfo and cacerts at runtime if it was used at build time.

2 Likes
4

The tricky thing is that a given use of core/go may not use those libraries. It would be a bummer to have to consume a runtime dependency for something you don’t need.

5

Want to start this thread again as we just found another of this in go as well.

Namely, depending on how you build your executable, you may get linked against whatever copy of core/glibc that core/go got built with. This can be completely different from whatever core/glibc resolves to in your build, especially if you are pinned to an older version of core/go.

Like we need a way for core/go to say it needs zoneinfo and cacerts at runtime if it was used at build time.

A potential alternative is something where the package declares some set of dependencies that aren't pulled in by default but are used for the purposes of version resolution. That is. If the user says "yeah, I need core/cacerts", then the version baked into core/go becomes a dependency for the version of detecting possible conflicts.

We could add to that some UI that alerts the user at build time that they might need to pull in some other dependencies.