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: better versioning support for go get #13700

Closed
marksalpeter opened this issue Dec 21, 2015 · 7 comments
Closed

cmd/go: better versioning support for go get #13700

marksalpeter opened this issue Dec 21, 2015 · 7 comments
Labels
FrozenDueToAge package-management
Milestone
Unplanned

Comments

@marksalpeter
Copy link

In my experience the lack of officially supported, built in, version control is the biggest pain point of the go language. This is a feature that a modern language, a language being built today in front of an active community of its users, should at least aspire to do well.

The Feature Request

I would like to see native support for version control built in to the go get utility. The syntax could look something like this:

import "github.com/user/package#v1-tag-name"

go get would function exactly as it currently does except that after a repo is cloned, it would check out the branch specified after the #.

For simplicities sake, you could add the following implementation details:

  1. If a package is imported with two different version tags in the same package, there could be a compile time "dependency error" of some sort
  2. In $GOPATH/src the directory structure could contain the package name with the tag appended to it. I think this will make the changes needed to implement this feature fairly minimal.
$ls $GOPATH/src/github.com/user/
package#v1-tag-name
package#v2-tag-name
package#v3-tag-name
package

Common Objections

I'm aware that the members of the core team are fans of the stable head methodology and that you would rather not needlessly complicate the logic of the go get utility. However, many people (myself included) have found some kind of versioning support very useful to the point where there are several competing package management solutions that I'm sure you have seen. I'm also aware that the team has added the vendor directory for experimental use. None of these solutions feel like real solutions to the problem. There is already an official dependency manager, it should support versioning.

Is there any chance that something like this could be put on the roadmap? Thanks!
@ianlancetaylor
Copy link
Contributor

Probably you should recast this in the form of a proposal (https://github.com/golang/proposal). The proposal should explain exactly what should happen if package A imports packages B and C, and B imports D#v1 and C imports D#v2.

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Dec 21, 2015
@ianlancetaylor ianlancetaylor changed the title Better Versioning Support for go get cmd/go: better versioning support for go get Dec 21, 2015
@marksalpeter
Copy link
Author

Is there a standard format of a proposal I should be aware of? Are there any examples I can reference? Also more broadly, in the go compiler is there a distinction made between packages nested within the package being compiled and packages from external sources?

@minux
Copy link
Member

minux commented Dec 23, 2015 via email

@marksalpeter
Copy link
Author

Thanks, I'll take a look!

@marksalpeter
Copy link
Author

marksalpeter commented Jun 30, 2016 •
edited

I know its been a while since I asked this question, but I would still like to see this addition. @minux You seem to be more knowledgeable about the compile time problems. To the question @ianlancetaylor originally proposed:

if package A imports packages B and C, and B imports D#v1 and C imports D#v2

the source tree would look like this:

src/A
src/B
src/C
src/D#v1
src/D#v2

First D#v2 and D#v1 would be compiled, then they would be linked to C and B, respectively, which would then be compiled and linked to A, which would then be compiled. This seems like a relatively simple solution to the problem.

A utility could be written to detect imports of different versions of the same package independent of the build or compile process. It would be up to package authors to use this utility at their own discretion. We could use notation similar to semver for the version numbers. Whenever go get is called it would simply obey the rules of the notation to retrieve and checkout the most recent allowable version of each package.

This seems like it would completely solve all of go's versioning problems with minimal overhead. Am I missing something that would make this a very complicated or undesirable change?

@ianlancetaylor
Copy link
Contributor

What you are proposing is that D#v1 and D#v2 will be linked together into the same program. For some kinds of packages that works fine. For packages that expect any sort of exclusive control over a resource, it does not. For example, the standard library expvar package registers an HTTP handler; therefore, it would not work to link together two different versions of the expvar package.

@trusktr trusktr mentioned this issue Jul 31, 2017
Closed
@bradfitz bradfitz mentioned this issue Dec 26, 2017
Closed
@ALTree
Copy link
Member

ALTree commented Aug 30, 2018

Fixed by modules, closing.

@ALTree ALTree closed this as completed Aug 30, 2018
@golang golang locked and limited conversation to collaborators Aug 30, 2019
@rsc rsc removed their assignment Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge package-management
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
7 participants
@bradfitz @rsc @minux @marksalpeter @ianlancetaylor @ALTree @gopherbot