deislabs/hippo-cli

Make a module available for import

itowlson opened this issue · 3 comments

In order for a HIPPOFACTS [[handler]] to use an external module, that module must be annotated with wagi_handler_id:

[[parcel]]
[parcel.label]
name = 'fileserver.gr.wasm'
[parcel.label.annotations]
wagi_handler_id = "static"

Hippofactory does not yet provide a way to do this - if you are building a 'library' module then you need to either bindle it directly or hippofactory -a prepare it and edit the invoice.toml.

It would be useful if hippofactory had a way to refer to modules such that:

  • They are not mapped to a route (because they are for use by other applications, not necessarily as addressable applications themselves)
  • They receive the wagi_handler_id annotation

We could reuse the existing handler table for this, but with a directive in place of a route, a la:

[[handler]]
exportId = "static"
name = "fileserver.gr.wasm"
files = []

Or we could define a new table, e.g. export:

[[export]]
id = "static"
name = "fileserver.gr.wasm"
files = []

In either case it could be mapped to a route as well (in the same table in the first syntax, by also having a handler entry in the second syntax). Though a module that belongs to an application and also exports itself as a library function feels like a recipe for disaster, and we could ban it if we wanted to, even to the extent of distinguishing libraries (specs that contain only exports) from applications (specs that contain only routes).

cc @technosophos @bacongobbler @thomastaylor312 @radu-matei for discussion and thoughts

My first inclination was towards the export table syntax, though I'm now feeling that changing the definition of the handler table might be easier. (Though obviously if we feel the export syntax is nicer then we should do that anyway.)

The difference in difficulty may have been more because I got the representation wrong. Currently prototyping based on export so speak up quick if you have opinions.

I agreed with the reworking you did in #35