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.

Sign up for GitHub

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

Jump to bottom

cmd/go: easier go.mod updates when packages are in the same repository #50698

Closed
dprotaso opened this issue Jan 19, 2022 · 3 comments
Closed

cmd/go: easier go.mod updates when packages are in the same repository #50698

dprotaso opened this issue Jan 19, 2022 · 3 comments
Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Unfortunate

Comments

@dprotaso
Copy link

dprotaso commented Jan 19, 2022 •
edited

Problem

For various reasons it's not always possible to host separate go packages in different source repositories.

Thus then you have multiple packages in the same repository and there's an dependent module it takes extra commits to just manage the module versions.

ie.

// go mod file located at some-repo/cmd/foo
module some-repo/cmd/foo

require (
  some-repo/pkg/heavy v0.0.0-{date}-{sha}
)
// go.mod file located at `some-repo/pkg/heavy/go.mod`
module some-repo/pkg/heavy/go.mod

require (...)

Updates to some-repo/pkg/heavy can't update some-repo/cmd/foo/go.mod directly and require two commits.

Thus the workflow is:

  1. Update pkg/heavy and commit the change
  2. Update the ref in some-repo/cmd/foo/go.mod to match the result of 1.

replace directives don't really work because it breaks go install for that command package

In this scenario the cmd package wants to continuously be in sync with the some-repo/pkg/heavy pkg. Which is effectively what the replace directive would accomplish.

Solutions

The goal is for a single commit to this repository to update both modules. The solutions below are suggestions and I'm open to any bike shedding or alternatives.

1. New keyword in go.mod

It would be great to annotate the dependency some-repo/pkg/heavy in the cmd package module file to signal it should always be the same sha. Thus a single commit can update both modules.

One solution could be introducing a new keyword to go.mod In the example below ibid denotes the dependent module is in the same repo. This ibid keyword is always present and never changes

// go mod file located at some-repo/cmd/foo
module some-repo/cmd/foo

require (
  some-repo/pkg/heavy ibid
)

2. Local references allowed in require blocks

This solution might have more readability

// go mod file located at some-repo/cmd/foo
module some-repo/cmd/foo

require (
  some-repo/pkg/heavy => ../../pkg/heavy
)

A more succinct version could be

// go mod file located at some-repo/cmd/foo
module some-repo/cmd/foo

require (
  // imports the module at the target path and reads it's go.mod file for the package name
  ../../pkg/heavy
)
@ianlancetaylor ianlancetaylor changed the title Easier go.mod updates when packages are in the same repository cmd/go: easier go.mod updates when packages are in the same repository Jan 19, 2022
@ianlancetaylor
Copy link
Contributor

CC @bcmills @matloob

@ianlancetaylor ianlancetaylor added GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed Proposal labels Jan 19, 2022
@bcmills
Copy link
Contributor

bcmills commented Jan 20, 2022 •
edited

I don't see how any of these approaches could work. In the Go module cache — and in the data served by module proxies — there is not in general enough information to associate two different modules to the same repository, let along the same commit.

The “module graph pruning” we added in Go 1.17 is intended to make it less costly to put different packages in the same module, which seems like a more robust approach in general. The “workspace mode” we are adding in Go 1.18 is intended to make it less tedious to author changes involving multiple modules, including multiple modules hosted in the same repository. We're certainly trying to improve the user experience for these use-cases, but the specific features suggested in this issue just don't seem to be feasible.

@bcmills bcmills closed this as completed Jan 20, 2022
@dprotaso
Copy link
Author

dprotaso commented Feb 3, 2022

I don't see how any of these approaches could work. In the Go module cache — and in the data served by module proxies — there is not in general enough information to associate two different modules to the same repository, let along the same commit.

I don't think the module cache needs to make such an association. I would just expect ibid literal to be realized as the same version of the current module. This intrinsically would only work for modules in the same repo.

The “module graph pruning” we added in Go 1.17 is intended to make it less costly to put different packages in the same module, which seems like a more robust approach in general. The “workspace mode” we are adding in Go 1.18 is intended to make it less tedious to author changes involving multiple modules, including multiple modules hosted in the same repository. We're certainly trying to improve the user experience for these use-cases, but the specific features suggested in this issue just don't seem to be feasible.

Can you elaborate how these features would avoid the necessity of creating two commits to update dependencies?

@golang golang locked and limited conversation to collaborators Feb 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Unfortunate
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dprotaso @ianlancetaylor @bcmills @gopherbot