Add support for multi-module apps about go-mod-vendor HOT 6 CLOSED

I agree with @ForestEckhardt that it is hard to come up with a reasonable solution to the problem without a real use-case. I am wary of building out a solution when the need here is mostly hypothetical at this point. I propose that we close this issue and address this concern anew if/when it surfaces again.

from go-mod-vendor.

@kvedurmu Do you have any examples of apps with multiple go.mod files? I was under the impression that was not a work flow that is natively supported in for Go.

from go-mod-vendor.

This was one of the issues pulled over as part of the Paketo migration. Unfortunately I can't find the original slack thread where this was requested, as it's pretty old. If I remember correctly, the true request here is to support building apps that are in a single repo with multiple modules (e.g golang/go#27056).

This to me seems pretty similar to what we support in the .NET Core Buildpack where users can specify project-path in a buildpack.yml. @sclevine do you remember the initial request around this? If not, I'm fine closing this one out.

from go-mod-vendor.

@kvedurmu
There are a couple things around this that I would like to address:

• The issue in question was never addressed and was closed due to inactivity almost a year ago, I would need some other use case or sample app in order to move forward on this.
• The concept of building multiple apps is not something the CNBs support, the idea (for the most part) is one app == one container.
• The project-path in .Net allows you to specify one path to the root of your project if it is not at the base of your application. The rest of the logic is handled by the .Net build system itself. The .Net Buildpack does not run multiple builds.

from go-mod-vendor.

@ryanmoran Can you speak any to this workflow?

from go-mod-vendor.

I think this request came from a Cloud Foundry team that was using multiple modules in a repo with local replace directives in go.mod so that they could depend on each other. This means that the buildpack couldn't be provided with a subdirectory of the whole repo -- it requires the whole set of modules in /workspace.

from go-mod-vendor.