Skip to content
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

cmd/go: [modules + integration] go mod pack, pack sources as module files #31302

nim-nim opened this issue Apr 6, 2019 · 2 comments

cmd/go: [modules + integration] go mod pack, pack sources as module files #31302

nim-nim opened this issue Apr 6, 2019 · 2 comments
modules NeedsInvestigation


Copy link

@nim-nim nim-nim commented Apr 6, 2019

This report is part of a series, filled at the request of @mdempsky, focused at making Go modules integrator-friendly.

Please do not close or mark it as duplicate before making sure you’ve read and understood the general context. A lot of work went into identifying problems points precisely.

Needed feature

Go needs an official go mod pack command that processes a set of unpacked Go modules and generates the corresponding packed module files for reuse (as specified in goproxy.)

This is different from issue #27858, because issue #27858 wants to put the generated files in the module cache, mixing them with modules of other provenance, and forbidding result reuse by anyone but the current user.


  • the feature should also be exposed as a function in the official Go API
  • the input set may be defined as one or several lists of of go.mod filesystem paths (as produced by go mod discover in issue #31299), one or several directory paths (similar to the directory paths defined in issue #31299), or a mix of both
  • the destination should be any binary directory path the user specifies
  • for compatibility with existing tooling, a separate optional prefix flag should allow pre-pending a path to the destination:
    • ie pretend working on destination, actually work on filepath.Join(prefix, destination)
    • that is typically used to prepare deployment to canonical_path, using a /prefix/canonical_path staging directory
  • to allow integration with CI/CD software, the command should optionally output a list of the files it created, in machine-readable format, to a user-specified result file
    • the result file path is not affected by destination
    • the result file lists paths without prefix, since the command is pretending to write directly into destination
    • this is similar to the behaviour of go mod build (#31323) and should use the same conventions
  • the command should use versioning info present in the info files discovered next to the corresponding mod files
  • the command should also take user-provided versioning info as input, either to fill in blanks when info files are not present, or to override them (both strategies could arguably be valid)
  • the command should tidy the mod files by default, removing unneeded requires (but see also #31318)
  • the command should work in secure no-internet-download mode. In that mode it should probably restricts its tidying to direct dependencies and the dependencies available in configured goproxy sources (#31304)
  • the command may also generate/update the corresponding list index files (but see also #31303 that is more general and is needed anyway)


Creating and managing a baseline of third-party code in a go module world requires the ability to generate the go module files that will serve as baseline blocks in separate CI/CD runs.

@thepudds thepudds changed the title [modules + integration] go mod pack, packing code as module files cmd/go: [modules + integration] go mod pack, packing code as module files Apr 6, 2019
@nim-nim nim-nim changed the title cmd/go: [modules + integration] go mod pack, packing code as module files cmd/go: [modules + integration] go mod pack, pack sources as module files Apr 7, 2019
@julieqiu julieqiu added the NeedsInvestigation label May 28, 2019
Copy link

@agnivade agnivade commented Oct 8, 2019

@bcmills @jayconrod

Copy link

@gopherbot gopherbot commented Oct 18, 2019

Change mentions this issue: zip: add package for creating and extracting module zip files

gopherbot pushed a commit to golang/mod that referenced this issue Nov 1, 2019
zip provides three new functions:

* Create - build a zip from an abstract list of files, filtering out
  files in submodules and vendor directories. This is useful for
  filtering a zip produced by a VCS tool (as the go command does).
* CreateFromDir - build a zip from a directory. This is a convenience
  wrapper for Create.
* Unzip - extract a zip file, checking various restrictions.

A list of restrictions on module paths, versions, files within zips,
and size limits is included in the package documentation. Both Create
and Unzip enforce these restrictions.

Also: copied cmd/go/internal/txtar to internal/txtar for testing.

Updates golang/go#31302
Updates golang/go#33312
Updates golang/go#33778

Change-Id: I6fedb8b839a0cd991c9b210e73bafedc4b286ec5
Run-TryBot: Jay Conrod <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Bryan C. Mills <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
modules NeedsInvestigation
None yet

No branches or pull requests

5 participants