-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for go packages with multiple go.mod in subdirectories? #1
Comments
Certainly, I'm actively looking for usecases like this. Can you provide some information on the directory layout and which Go packages in that tree you are attempting to build? |
The package in question is kubeflow: it has a plethora of |
Documenting the Go module structure of kubeflow source here as a means of constructing a general use case for Locations of
All Directories in the source tree containing
|
I've run into a similar issue packaging golang.org-x-tools-gopls which is a sub-project of golang.org-x-tools-gopls. Since this is contained within the sources of golang.org-x-tools-gopls as a subdirectory with its own go.mod, obs-service-go_modules presently is unable to handle it: it will find and tar up the dependencies in the top directory. Thus, an option to specify directories where to look for go.mod files would be useful. |
So far the go.mod in the topmost directory was picked. This is not always what is expected: a Go-project may be a sub-project inside another project. In this case it would reside in a sub-directory. This patch makes it possible to specify this directory. See also: openSUSE#1 Signed-off-by: Egbert Eich <[email protected]>
I have the same problem with etcd version 3.5.0. etcd provides multiple executables and each has its own go.mod. etcd project seems to encapsulate multiple executables/projects in one repository. The current solution that I used was to add a vendor tarball for each executable manually, but I would like to have some automation. One option is to add some parameters to <service name="go_modules" mode="disabled">
<param name="archive">etcd-3.5.0.tar.gz</param>
<param name="output">vendor-etcd.tar.gz</param>
<param name="gomod">server/go.mod</param>
</service>
<service name="go_modules" mode="disabled">
<param name="archive">etcdctl-3.5.0.tar.gz</param>
<param name="output">vendor-etcdctl.tar.gz</param>
<param name="gomod">etcdctl/go.mod</param>
</service> Would be nice to have an argument to tell where the go.mod lives and what the output name should be. Another option is to automagically find all go.mod files and create multiple folders inside
This way I can unpack the vendor folder in the desired location. I'm willing to implement one of these solutions and send a PR. |
So far the go.mod in the topmost directory was picked. This is not always what is expected: a Go-project may be a sub-project inside another project. In this case it would reside in a sub-directory. This patch makes it possible to specify this directory. See also: openSUSE#1 Signed-off-by: Egbert Eich <[email protected]>
So far the first instance of go.mod found was picked. This may cause issues if multiple go.mod files are in a repository with sub-projects. Now we assume go.mod will reside in the top-most directory unless specified otherwise thru a command line option. Note: We keep this separate from the --basename option: the latter will most likely contain a version number and will require a change every time the package is updated, yet it is expected that subdir will be used more frequently. This addresses: See also: openSUSE#1 Signed-off-by: Egbert Eich <[email protected]>
So far the first instance of go.mod found was picked. This may cause issues if multiple go.mod files are in a repository with sub-projects. Now we assume go.mod will reside in the top-most directory unless specified otherwise thru a command line option. Note: We keep this separate from the --basename option: the latter will most likely contain a version number and will require a change every time the package is updated, yet it is expected that subdir will be used more frequently. This addresses: See also: #1 Signed-off-by: Egbert Eich <[email protected]>
I'm currently trying to package a go application, that uses go modules but whose
go.mod
lives in a subdirectory (actually it has multiplego.mod
for a few subpackages, but I haven't got that far yet). I've looked at the code and it appears that ago.mod
in a subdirectory is currently unsupported.Would you consider adding support for that? And maybe for multiple
go.mod
from the same archive too?The text was updated successfully, but these errors were encountered: