Should go-mod-vendor provide a dependency for downstream buildpacks? about go-mod-vendor HOT 3 CLOSED

The issue that I think you are running into here is that it is not possible for buildpacks to intercommunicate during detection. I think that there are two clear ways of doing what you are trying to accomplish based on what we do in the rest of the buildpacks ecosystem.

Change the build plan

Change the build plan of the the go-mod-vendor buildpack to the following:

[[provides]]
name = "go-modules"

[[requires]]
name = "go"

This would then allow you to in the go-module-bom buildpack to have the following build plan:

[[requires]]
name = "go"

[[requires]]
name = "go-modules"

That would force a direct requirement between go-module-bom and go-mod-vendor. The only disadvantage to this is that the build plan for go-build would also need to be updated to accommodate for non go mod apps meaning we would need a build plan that looks similar to the following.

[[requires]]
name = "go"

[[or]]

[[or.requires]]
name = "go"

[[or.requires]]
name = "go-modules"

I think that this API change is unattractive but functional so I could be convinced however this is a lot of changes just to make there be a build plan level relation between go-mod-vendor and go-module-bom

Just detect on file existence

I think that the other option that is possible is to detect on similar criteria to that of the go-mod-vendor buildpack and then place is later in the buildpack order. This has the distinct advantage of requiring no changes to the existing buildpack build plan APIs however it does mean that there is not a built in link between the app being vendored and the bom generator running. In the case of our metabuildpack we would ensure this behavior by placing the buildpack later in the build order but this has the potential to cause suboptimal if not broken behavior for individuals that decide to build custom buildpack orderings.

My 2 cents

If I had to chuck some of my own opinion into the mix I think that if you want the initial implementation of the buildpack to happen more quickly I would go with the similar detect logic option. It is the fastest way to get yourself up and running and if a direct buildpack relation becomes necessary it is something that can be implemented later with a relatively low amount of cost. However, if y'all want to try and make a case for setting up the contract right away that is also reasonable it just might take a little long.

from go-mod-vendor.

(Not a maintainer) I think the proposed bom-buildpack should be independent enough to be utilized by a user that do not want vendoring, i.e. it should be usable along with just go-dist and go-build buildpacks.
Doesn't the bom-buildpack (or the tool used there) have to generate the bom regardless of if the vendor directory is populated? Because even if the app is not vendored, I believe packages will be downloaded into the go-cache dir during compilation which is part of the final image. (Not sure if I have the full picture of the bom-buildpack as my knowledge is only from the post here). So my $0.02 would be against an API as I don't really see a provides-requires relationship here.

from go-mod-vendor.

The issue that I think you are running into here is that it is not possible for buildpacks to intercommunicate during detection.

@ForestEckhardt - bingo. I think that's the aspect of the architecture I was missing.

@arjun024 Currently the proposal for the Golang BOM buildpack is that it will only support go mod. But I take your point that it's possible that we might want to see it broaden support in the future to include go dep (or, possibly, vendored dependencies that do not have a package manager)** . That possibility alone is a useful reason not to tightly couple the Go BOM buildpack to the go-mod-vendor buildpack. And, following that thought, if we don't want to closely couple the BOM buildpack to the go-mod-vendor buildpack, the provides-requires relationship becomes less valuable. Also, I agree with your point that the go BOM buildpack doesn't strictly need the go-mod-vendor buildpack to have run first, though it would likely execute faster if that were true.

I think it's pretty clear that we will want the go BOM buildpack to evaluate the presence of the go.mod file independently of whether go-mod-vendor has detected. Practically, that likely means either we copy the detection/parsing code from this buildpack, or we extract it into a library that is consumed by both buildpacks. However, that can be a separate issue.

Thanks for all the help folks - I think we have a clear path forward now.

** I really doubt we would ever want the BOM buildpack to support dep or other vendoring alternatives, as the only officially supported vendoring model is go mod (dep was deprecated in 2020). But the point stands for a discussion about architecture between buildpacks.

from go-mod-vendor.