CC @taking @alandonovan

If you mean that packages.Load as it exists today should work without requiring Go to be installed, that generally seems like a bad idea to me. You could potentially do it by embedding the entire Go toolchain and standard library into the binary (hundreds of megabytes!), to then extract it in a temporary directory and use it.

A simpler alternative, if you only need ASTs, is https://pkg.go.dev/go/parser#ParseDir. That does require you to have the Go package already on the filesystem somewhere, but it then means you don't need go/packages at all.

@mvdan , thks for the feedback. I retract the proposal.

You could potentially do it by embedding the entire Go toolchain and standard library into the binary (hundreds of megabytes!), to then extract it in a temporary directory and use it.

That would be doable indeed but complex to implement from my perspective. My idea of the go standard library is to provide functions with most complexity hidden from the programmer. BTW : indicating in the package.Load() documentation that the go tool need to be installed in the execution environnement would be a plus in my opinion.

A simpler alternative, if you only need ASTs, is https://pkg.go.dev/go/parser#ParseDir.

Thank-you for pointing this but the example above needs a bit more than the results of the of parser.ParseDir() function.

Field: models.Country{}.Hello,

In order to construe the link between the Country shape and the Hello shape, the UML diagram unmarshaller needs to know that the type of the Hello field is of type pointer to Hello struct. The unmarshaller get the type of association fields by packages.Load().. Maybe I am mistaken but getting the type would not be possible with parser.ParseDir() (the type is within the package).

PS : a workaround is possible with parser.ParseDir() but this is not the proper forum for this discussion

@mvdan , thks for the feedback. I retract the proposal.

Thanks for writing up your interesting use case so clearly.

The root of the problem is that the go list embodies a lot of computation on Go workspaces that it would be infeasible to maintain as a linked library. Also, golang.org/go/packages is intended to work with other build systems than go, such as Bazel and Blaze.

In system engineering, it is interesting to ship simulation binaries to interested stakeholders.

I would have thought that a stakeholder who cares about the code at the level of UML diagrams would be working in an environment where 'go build' works. But if not, perhaps you could package your program as Linux container image that contains a Go toolchain.

The root of the problem is that the go list embodies a lot of computation on Go workspaces that it would be infeasible to maintain as a linked library.

@adonovan , thks for the explanation. I admit that when I used packages.Load() for the first time, I was a bit amazed that a simple go program could perform such a go compilation by itself. I only discovered later that there was a go system call (after sharing the binary on a file server with a stakeholder who had not go installed :-)).

I would have thought that a stakeholder who cares about the code at the level of UML diagrams would be working in an environment where 'go build' works.

For your information, there is a recent trend in system engineering where stakeholders routinely deal with complex custom data model to explore their problem domain (see ref. below). Data model, also named ontology, can be complex (for instance in the model I currently work with, there are 40 classes and 61 associations). For stakeholders, it is natural to navigate the ontology/data thanks to a UML diagram (this is the use case # 1). Most stakeholders do not know that this is a UML diagram, they see (and understand) a diagram of interrelated concepts.

Ernadote, Dominique. "An ontology mindset for system engineering." 2015 IEEE International Symposium on Systems Engineering (ISSE). IEEE, 2015.

This proposal has been declined as retracted.
— rsc for the proposal review group