A lib (meaning /pkg) where we're forced to return a Version (considered /internal)

[dionysius]

Generally I'm still unsure about pkg, but lets keep that there #10. It still applies that you need your lib for external use must be independent from internal stuff.

Assuming I'd like to follow the current project-layout consensus, especially /pkg and /internal:
I have a lib implementing this requiring the implementer to return its app's current version here.

Now, the app's current version lays perfectly somewhere in /internal and I really like not to have an include into /internal.

1. I could define a version string parameter, Version field in a struct or SetVersion(version string) method and such. That approach looks messy, as I probably would have to carry that option multiple "layers", but the caller has ultimate choice. But I don't like the option at all, that the caller has to set a version...
2. I could also see, that the resulting version is indeed dependent from my lib (code-wise), but the meaning of that field is definitely practical (should return the version of the binary running - so not the "lib-version")
3. It could depend on the "caller/user" to either want 1. or 2. (= variant 1, or set it with help of 2. with the package variable).
4. But this package variable is set on build-time with -ldflags, so someone importing that code will never get the real version.

Your thoughts from your angle?