-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: extend syntax go.mod to allow overriding fetch protocol #39536
Comments
I'm a bit confused by the proposal - If we start allowing full URLs in replace directives, should we also allow them in other places that usually get import paths, such as What should happen if I tell Have you thought about modules where the import path is not a git server? For example, https://mvdan.cc/sh works, but git+ssh://mvdan.cc/sh will not. Conversely, git+ssh://github.com/mvdan/sh will work, since that's the repository URL. But of course, the two URLs are not the same, and |
I'm not sure I got this part right, please, correct me if not. The current restriction is that I didn't explicitly (or implicitly) proposed to support the whole URL. More to that, I think w/o a formal definition of what is the difference between "package", "module" and URL, the discussion might become very confusing. We can consider adding the protocol to the existing syntax of Regarding the conflicting cases, we should come up with the priorities, yes. I expect that a package, which is replaced with FS-based replace, isn't affected by |
So, in a way, these URL-based replaces would be like local directory replaces - just pointing at a remote location/machine. That makes more sense to me.
I would certainly expect Similarly, I think supporting You can't assume that the other end will be a git repository or clone, either. This applies for local directory paths, and by extension, your URLs too I would say.
Assuming we piggyback off of local directory replace directives, I agree that these rules become clearer. |
Exactly. I don't know yet the deeps of the current implementation. But when I wrote the proposal, this was exactly how though about it 👍 |
The nice property of filesystem-local |
@bcmills I feel there is a confusion or maybe I don't follow this part:
It could be, that the description didn't show the idea clearly — I will appreciate suggestions to improve the wording — but I expected the same behaviour for |
@narqo, the If what you have in mind is analogous to the behavior of |
Good point. My initial hopes were to piggyback the existing
That is, What do you think? |
#33985 is closely related. See in particular #33985 (comment): if you have N repositories, then you potentially have N² |
If the purpose of this proposal is to avoid needing to run an HTTPS server serving So I think first we need to understand where the current options are falling short: what happens if you use a |
I don't think I understand how
My company uses private github repositories. In order to use Go modules in our projects, every developer or a contributer, has go through the additional onboarding, where they tune their |
Does If it does work, and the problem is that the versions don't track, then it seems like this could be solved less invasively using #28176. |
As far as I can tell it does not work with @bcmills, if a user could do
forcing the use of |
Wait, you initially said
|
My company is also using private git repos over ssh, via a one-time The above workaround does indeed work, but A) it requires additional configuration in every
It'd be nice if this manual process was not required. Even with #28176 resolved, a better approach might be to integrate the package<>VCS mapping into the existing one-time machine configuration (not per package) -- something like #45611. |
Update
The original proposal was build on the idea that we could extend
replace
directive (see the original text below).After several rounds of discussions here in the comments, the current semantics of
replace
isn't about fetching the dependency but about local substitution of the source path and version (see this comment from @bcmills).I have re-title the proposal and suggested the new syntax to solve the described problem.
Original Proposal
I propose to extend the syntax of go.mod's
replace
directive to support overwriting the protocol, which Go will use to fetch the module. That isBackground
As it’s for Go 1.14, the syntax of
replace
directive ingo.mod
allows overwriting module’s import path by defining an alternative version, alternative import path, or a path on the local FS (refer to [1]).For non-FS-based replaces, Go fetches the replaced modules from modules proxy server as it does for other dependencies.
If a project uses private dependencies or private forks to replace a dependency, managing the modules become an extra burden for the developers, who work on the project. Even though the dependency is an attribute of the project itself, it’s the responsibility of every developer of the project to define the correct values for
GOPRIVATE
,GONOPROXY
, etc, which alters their "normal" development workflow.With private dependencies explicitly listed as the ones, that can't be fetched from any modules-proxy server, the project's workflow wouldn't be any different from a project, that only uses public modules (providing that a developer has the required accesses).
Specifying the protocol explicitly would also solve the issue where “go get” chooses to fetch a private dependency via HTTPS, which usually forces developers to manipulate their host’s
.gitconfig
, adding custominsteadOf
rules to force go-get to use SSH when downloading modules from GitHub repositories.Prior Experience
Dependency-management systems in other programming languages have similar mechanisms. For example:
Node.js + NPM
package.json
"dependency"
syntax accepts URLs, Git URLs and some other [2].Rust + Cargo
Cargo.toml
allows overwriting the source of the dependent crate, passing project’s Git URL [3].Go + dep
Gopkg.toml
allows specifying dependencies'source
as an alternate location, passing the URL [4].The text was updated successfully, but these errors were encountered: