Pluggable Language Helper Support

ollerhll commented 7 years ago

The Problem

Currently LanguageHelpers are part of the CLI source code. This means that support for a given language must be hardcoded in, forcing users to re-download the CLI every time a new language is added, and also not allowing people to provide support for their own language of choice.

Proposed solution

Implement the language helpers as a docker image-based plugin, downloaded/run upon calling fn init or fn build. This has a number of benefits:

New languages can be added without updates to the CLI source.
Users can provide support for their own languages.
Language support can be written in any language (no need for contributors to learn Go!)
Users can add support for a language for personal use without needing the blessing of the Fn team.
Slightly simplifies the CLI codebase (both init.go and common.go will become slightly less complex, and the langs directory is entirely removed.

Details

Currently the plan is as follows:

Each LangHelper now takes the form of a docker image.
When fn init or fn build is called, the CLI will run the container from that image, and retrieve the information required as a JSON encoded struct.
The container will also produce any side effects produced as necessary (boilerplate generation, and prebuild stages
The CLI will ascertain which docker image is required in one of two ways. Either, the --runtime flag (or the runtime field in the func.yaml will directly refer to a docker image, in which case that image will be pulled from Dockerhub - this is what allows users to use non-official images for their projects.
If the --runtime flag does not refer to a docker image (i.e. it does not contain a /), then the image name required is decided dynamically using a naming convention that is yet to be completely decided, but something akin to fnproject/fn-langhelper-$RUNTIME:latest.

Progress

I have begun work on this already, and am approaching a presentable proof of concept in the form of a docker plugin for the java LangHelper; discussion and feedback is greatly welcomed.

tl;dr

To provide an easy, flexible, and pluggable way for developers and users to add support for a given language, without updating the CLI source code.

zootalures commented 6 years ago

hibooboo2 commented 6 years ago

@rdallman @zootalures This affects what I am doing on the severless integration and I would like to reopen this convo so that we can figure it out. Since duplicating and maintaining what the language helpers do in the cli to the serverless integration would be a hassle and not maintainable.

hibooboo2 commented 6 years ago

👊 Bump

zootalures commented 6 years ago

@hibooboo2 This work/branch is currently on hold - what are you proposing exactly? Not exactly clear how the serverless integration dictates things here?

hibooboo2 commented 6 years ago

Was hoping to separate language helpers from the cli so that they could be used by serverless. After our convo, seems better to leave as is and just dup for now. So will go that route.

fnproject / cli