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

proposal: cmd/go: allow replacing a subdirectory within a package #30886

Closed
nhooyr opened this issue Mar 17, 2019 · 3 comments
Closed

proposal: cmd/go: allow replacing a subdirectory within a package #30886

nhooyr opened this issue Mar 17, 2019 · 3 comments
Labels
FrozenDueToAge modules Proposal WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@nhooyr
Copy link
Contributor

nhooyr commented Mar 17, 2019

Right now, the replace directive only allows replacing modules with different modules.

It'd be nice if you could just replace a single sub package within a module with a different package elsewhere in a different module.

My use case is that right now goimports does not support reordering imports when there are multiple groups (#20818) and so I forked golang.org/x/tools.

Right now, I have to replace the entire module with my fork. I only modified golang.org/x/tools/imports so I only want to replace that package with the package from my fork. I don't want to maintain my fork and keep it up to date to use new additions to golang.org/x/tools. I only want to maintain the golang.org/x/tools/imports package.

@katiehockman
Copy link
Contributor

I'm not sure that's the right approach here, since the go.mod files define module paths not packages. Allowing replace directives at the package level within a go.mod file seems a bit strange to me.

/cc @bcmills

@agnivade agnivade changed the title cmd/go: allow replacing a subdirectory within a package proposal: cmd/go: allow replacing a subdirectory within a package Mar 22, 2019
@agnivade agnivade modified the milestones: Unplanned, Proposal Mar 22, 2019
@bcmills
Copy link
Contributor

bcmills commented Mar 28, 2019

The term “module” as applied to software development is a self-contained unit of code. We specify module requirements at the granularity of individual modules, so it's not at all obvious to me how a replacement for only part of a module would interact with requirement resolution.

As a proposal, this would need a lot more detail, and even then I think it's unlikely that the marginal value would outweigh the increase in complexity (both for users and in the implementation).

For this concrete case, #20818 is still marked as Proposal-Approved. Is there a reason you cannot contribute your fixes upstream?

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Mar 28, 2019
@nhooyr
Copy link
Contributor Author

nhooyr commented Mar 28, 2019

Sounds fine to me.

For this concrete case, #20818 is still marked as Proposal-Approved. Is there a reason you cannot contribute your fixes upstream?

No, just wanted to use it immediately without changing all import paths.

@nhooyr nhooyr closed this as completed Mar 28, 2019
@golang golang locked and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules Proposal WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

5 participants