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

Comments

Projects
None yet
4 participants
@nhooyr
Copy link
Contributor

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 katiehockman added this to the Unplanned milestone Mar 19, 2019

@katiehockman

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2019

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

This comment has been minimized.

Copy link
Member

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?

@nhooyr

This comment has been minimized.

Copy link
Contributor Author

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 Mar 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.