Separate api layer apply-setters

[phanimarupaka]

This PR is to move apply-setters api layer to applysetters package so that it is reusable. main.go deals with the cmd/function framework. apply-setters/api package holds core reusable logic.
Addresses kptdev/kpt#1832

This PR also addresses kptdev/kpt#1870

cc @yhrn

[yhrn]

@phanimarupaka Thank you for getting to this so quickly. Can I also request that when you create a new release of the function to make sure that the tag matches the actual repo path? The latest apply-setters release tag was go/apply-setters/v0.1.0 but the path to it is functions/go/apply-setters/v0.1.0.

[frankfarzan]

PR incorrectly refers to searchreplace.

[mengqiy]

Can I also request that when you create a new release of the function to make sure that the tag matches the actual repo path? The latest apply-setters release tag was go/apply-setters/v0.1.0 but the path to it is functions/go/apply-setters/v0.1.0.

There is no plan to make the release tags match the full path. We want to make the release tags shorter.
@yhrn Why do you want to have that?

apply-setters/api package holds core reusable logic.

This is out-of-date. There are no api package now.
We will not stop our users from using the package, but currently we don't plan to support the package as our API.

[yhrn]

There is no plan to make the release tags match the full path. We want to make the release tags shorter.
@yhrn Why do you want to have that?

@mengqiy I'm a bit lost here, the point of my original ask was so that I could make a more complex function that also includes applying setters. So I would like to be able to do go get github.com/GoogleContainerTools/kpt-functions-catalog/functions/go/[email protected].

[phanimarupaka]

@yhrn The request was to separate it out of main package. You can reuse code in core applysetters package with this change.

[mengqiy]

@yhrn I got what you meant.
Even though we have git tag go/apply-setters/v0.1.0, go get doesn't allow us to do go get github.com/mengqiy/kpt-functions-catalog/functions/go/apply-setters@go/apply-setters/v0.1.0. The work around is use its corresponding SHA.
If we have a git tag functions/go/apply-setters/v0.1.0 which matches the path, go get will allow us to do go get github.com/mengqiy/kpt-functions-catalog/functions/go/[email protected]

[yhrn]

@phanimarupaka yes, and that is the most important thing for me, but I just thought it followed naturally that I would also like to be able to take a dependency on a specific release version so that is why I was a bit surprised at the question on why I wanted a tag matching the repo path of the function.

However, I could rephrase and ask if it would be possible to also create a full path tag that matches the release? For example if you release go/apply-setters/v0.1.0 (or maybe something shorter in the future like apply-setters/v0.1.0) could you also tag the same commit with functions/go/apply-setters/v0.1.0? The second tag wouldn't need to be a release, just a plain tag.

[yhrn]

@mengqiy Yes exactly - didn't see your response before my previous comment.

[phanimarupaka]

@yhrn Couple of things here

1. Changing the naming pattern(to functions/go/apply-setters/v0.1.0) would solve the problem, talked to megqiy and we will be doing that.
2. We version/release function packages based on the behavior changes(for e.g. the way we handle setter types) and not based on the api/code changes(e.g. If we make a private method public, we don't make a new release. You will have to wait till the next release to use that method). As long as you are aware of that, you can fetch and reuse the core logic of the functions.

cc @frankfarzan