Allow passing a list of packages to be included

[jonlundy]

I am looking for something similar to how the std mode works but where i have a number of related repos that i would like parsed together into one generated output.

Example: golds -wdpkgs-listing=promoted x.y.z/myapp1 x.y.z/myapp2 x.y.z/myapp3 x.y.z/myappN

where all of the packages related to the list provided are included in the promoted.

x.y.z/myapp1 
x.y.z/myapp1/cmd/bin 
x.y.z/myapp2
x.y.z/myapp2/internal/foo
x.y.z/myapp2/internal/bar 
x.y.z/myapp3
x.y.z/myapp3/pkg/baz
x.y.z/myappN

...other packages...

[zigo101]

Is each of the projects in a separated module?

[jonlundy]

Yes

[zigo101]

Yes

I assume that your projects (appN) have a go.mod file in their respective root directories.

It is a restriction that only one (non-major) version is chosen for each module in the current implementation.
So in theory, if two of appN projects depend on two different versions of a module, golds will fail to process.
And in current implementation, to prevent such situations happening, golds only supports parsing one Go project in each run.

The restriction comes from the https://pkg.go.dev/golang.org/x/tools/go/packages dependency used by golds.
It needs much efforts to overcome this restriction.

If you can make sure that your projects don't depend on two different versions of a module, here is a (some inconvenient) workaround:

• create a temp directory and create a go.mod file which specifies a line module x.y.z.
• copy all your appN projects into the directory and remove all the go.mod files in them.
• run golds in the temp directory

[jonlundy]

I will try that

[amery]

shouldn't tools/go provide mechanisms to resolve a dependency graph before you compute the details? @go101

[zigo101]

golang.org/x/tools/go/packages (and Golds) behaves the same as go build.
If go build module1 module2 succeeds, then golds module1 module2 should too.