Internal getting in the way of generated code

[javier]

I have a code generation tool that is currently being blocked by use of internal package not allowed compilation error. In more detail (question at the end of post):

Throughout many go services I create metrics, in the pseudo-code form:

func init() {
    someMetric := metrics.New(...)
}

Additionally I have recently added rules on this metrics through a rules package, of the form:

func init() {
    someMetric := metrics.New(...)
    rules.New(someMetric, ...)
}

The rules package takes the form:

package rules

var AllRules = make([]*rule, 0)

func New(someMetric metric.Metric, opts interface{}...) {
    rule := newRule(someMetric, opts) // implementation omitted
    AllRules = append(AllRules, rule)
}

This has no functionality in normal services, however I am generating a main.go of the form:

import(
    _ {some package}
    _ {another package}
    etc... all packages here
)

func main() {
    // iterate over rules.AllRules 
    // and generate a config file which I provide to to my monitoring system
}

(why I do this? Previously my rules and metrics easily got out of sync with refactoring and code changes, this way I get runtime-checks and always up-to-date rules when I ran my generated main.go)

My problem is that as part of those packages I have /internal/ packages that fail compilation of my generated main.go.

I have a hacky solution which is disabling disallowInternal in cmd/go/internal/load/pkg.go, compiling my ‘internal-disabled’ golang and using that instead of the standard go.

My question is: Is there a better solution which doesn’t involve changing go? If not, can I add a boolean flag to go tool compile, ignoreInternal (or whatever) in a PR?

[calmh (Jakob Borg)]

The thing with internal is all about your package structure. You’re not telling us anything about your package structure. Certainly there are solutions that don’t involve changing Go, but being specific is difficult without knowing anything about your package structure. Generally speaking, don’t create internal packages if they are not going to be used internally only.