[New Repo] knative-sandbox/func-go

[lance]

[New Repo] knative-sandbox/func-go

[evankanderson]

It was brought up that git tagging for versions might be better if we had per-language libraries.

[lance]

Would it make sense to create a monorepo of sort to cover for the future expansion maybe?

E.g. knative.dev/func-runtimes/go is still a nice import path. :)

Sure I am OK with that too. I think probably we could still keep the import path as knative.dev/runtime with a redirect from github.com/knative-sandbox/func-runtimes/go.

[evankanderson]

We probably also want these to be library-semver-versioned, rather than Knative-service versioned.

[lance]

Note that this repo currently exists (with a single commit) at: https://github.com/lance/func-go

[psschwei]

Are you thinking of doing similar repos for other languages, e.g. func-python, func-node, func-cobol ... ?

[lance]

Are you thinking of doing similar repos for other languages, e.g. func-python, func-node, func-cobol ... ?

The other runtimes all have frameworks that they use which are not maintained within the knative/knative-sandbox orgs. For example boson-project/faas-js-runtime and boson-project/parliament. I did not have any real intention of moving those here, as there is no real demand for it and it doesn't buy us anything (other than perhaps more eyeballs, which is arguably a good thing).

The motivation for moving the golang framework here is that it really does need to be separated from the buildpack itself to enable any go-capable buildpack to work (or s2i) or some other build strategy we have not enabled yet. The invocation framework should not be hidden within a builder (and likely duplicated to other potential builders), but instead be declared as a dependency on the function. That's the primary motivation for the change. Ideally, I'd like the package to be a part of knative.dev as there really is not much use for it outside of the project.

I suppose it's odd that I am not proposing to move the other frameworks here. I'd be willing to discuss it for sure. I seem to recall some opposition to that when we first donated the project. I could be misremembering, so I'm open to revisiting the idea.

[dsimansk]

Would it make sense to create a monorepo of sort to cover for the future expansion maybe?

E.g. knative.dev/func-runtimes/go is still a nice import path. :)

[psschwei]

I suppose it's odd that I am not proposing to move the other frameworks here. I'd be willing to discuss it for sure. I seem to recall some opposition to that when we first donated the project. I could be misremembering, so I'm open to revisiting the idea.

No issues from with just moving the go framework, just wasn't sure if this was something go-specific or part one of a larger migration you had planned (though I probably could've figured that out if I had clicked on the buildpack link before commenting 😄).

I also like the monorepo idea. edit: TOC discussion brought up reasons why monorepo might not be good (see below)

[lance]

We probably also want these to be library-semver-versioned, rather than Knative-service versioned.

@evankanderson if we forego the Knative versioning, what elements of Prow, hack, etc. should we include in this repo? Are there recommended practices for the Knative org to manage versioning for small sub-projects like this, beyond repository tags and the like? I have been a big fan of release-please in other, smaller projects and this might work well for module versioning, tagging and changelog here. OTOH, if there are Knative-recommended ways of handling these things outside of the standard Prow based workflow, I'm happy to adopt those as well.

[zroubalik]

Wouldn't be func-go-runtime a better name?

By seeing func-go one could get the impression that it is some kind of go version of func.

[lance]

@zroubalik if we end up moving Node.js and Python runtimes to knative-sandbox as func-node and func-python maybe that will help clarify?

[zroubalik]

@lance I think it will bring more confusion 😄 I would think that these repos are node and python implementations of func not the runtime.

The best name would be imho func-runtime-go, func-runtime-node,...

[dprotaso]

@lance is this still in progress?

[lance]

We are using https://github.com/knative-extensions/func-go - I think this can be closed. Thanks for the ping @dprotaso