Extend entrypoint parameter

[MHHukiewitz]

In reference to aleph-im/aleph-vm#482.

Allows distinction between different types of plain code executions and more freedom in defining how it should be run.

[hoh]

I am afraid that this approach would not be easy to maintain. What about splitting the different components ?

    encoding: "squashfs"
    entrypoint: "main:app"
    language: "python"
    interface: "asgi"
    ref: ItemHash
    use_latest: bool = False

    encoding: "squashfs"
    entrypoint: "run dev"
    language: "javascript"
    interface: "npm"
    ref: ItemHash
    use_latest: bool = False

    encoding: "squashfs"
    entrypoint: "http_server.exe"
    language: "golang"
    interface: "executable"
    ref: ItemHash
    use_latest: bool = False

[MHHukiewitz]

• Does language really make sense here? There are tons of apps that might run a combination of multiple languages, what matters mostly is interface, as you proposed.
• Should additional args be passed along in the entrypoint field? Might a list of args be easier to integrate?

[MHHukiewitz]

Just highlighting the changes from a29de08. Introducing default values to classes of fields of our message classes lead to verification errors on the check_item_content validator. Setting a default value would result in validation failing. Which brings me to the following question:

Parsing past messages without the default values would lead to mismatch in item_content and item_hash (I just realized).

• How should we then treat the model instead?
  • Make new properties always optional?
• Will there be a migration of models at any point in the future?
  • Might we just store the original and then update it according to our migration rules to some kind?
  • Will there be different views on the message (original, implicit)?

[MHHukiewitz]

@hoh good to go