gen_imports is not useful for embedded interpretter

[ajwerner]

Say I want to embed gomacro in an application that is not connected to the internet and I really do not want to go off and compile new imports. I do, however, want to empower users to be able to import and use a number of package. I'd like to generate the binding for these packages ahead of time and compile them in. The -g flag generates exactly the sort of thing I'd like to have generated but it always puts it in the source tree of the dependency. This seems bad in a number of dimensions. I want to be able to specify the file path and the package name for the generated file.

I also think my user story here is, to some extent, bumping up against some module limitations I don't really understand. I would think that I don't need those things I'm generating to be in my GOPATH but rather in the go.mod for my project.

Does this all make sense? I'm happy to look into some of this. The generation stuff doesn't seem particularly hard, just plumbing.

[ajwerner]

I'm thinking I'd add a new types.ImportMode, maybe ImEmbeddedThirdParty, ends up being a mashup between ImThirdParty and ImInception with some differences. It is an external package to both the imports package and the package being generated and is going to write the file elsewhere.

Then from the command line we'd need to plumb in the name of the package in which the new file will live and the path to the file (or directory if we want to derive the filename). That's all not too hard. I do wish this stuff could work within modules.

[cosmos72]

I thought about your use case, and it's very similar to ImPlugin:

create bindings for package X, where the bindings are external to both

• the package X being imported
• the package Y (gomacro or some other interpreter) that wants to import X

The main difference is that ImPlugin always creates such bindings in a package B = gomacro.imports/path/to/package/X
where instead you want to be able to manually specify B.

There is also another, minor difference:
ImPlugin puts the definition of type Package = struct { Name ...; Binds ...; Types ... } in the same file as the bindings,
while you may want to put such type definition in a separate .go source, to share it across all other .go sources
in the same directory - but that's easy to do, and doing it does not break ImPlugin

For these reasons, I think you will have an easier time by extending ImPlugin to accept the name of package B where to create the bindings, and keep the current behaviour as default (i.e. if no name is specified for package B)

Does it make sense to you?

[ajwerner]

Yes, that makes sense. I'll give it a shot when I get a shot when I get a chance.