4 ms·

It’s an elegant solution for packages that don’t use versioning features like git tags. For every other package out there that uses git tags, it’s just a lazy

It’s an elegant solution for packages that don’t use versioning features like git tags. For every other package out there that uses git tags, it’s just a lazy solution: why on earth would I want to specify the version in the path? Git tags solves that problem in a more elegant way (both from the side of the maintainers and users).

paskozdilar 5y ago
> it’s just a lazy solution: why on earth would I want to specify the version in the path? It's not a lazy solution, just opinionated. Personally, I love the fact that just by seeing the import path I know exactly which codebase is used. I don't have to open my go.mod, see which version I'm using, clone the repository, dig through the history to check out a specific tag and see what code is actually used in my program... I just open the repo in my browser and browse through the directories. There isn't a single system on earth that doesn't support directories! I also love the fact that I don't have to know s**t about git to use Go. If Go was to suddenly switch to git tags, not only would it break a massive amounts of existing code, but would basically force everyone to learn about git tags just to be able to see what code are they using, which would raise the amount of paperwork I have to fill in order to work on the thing I care about. Go is fundamentally against needless paperwork.
- Dylan16807 5y ago
  > I just open the repo in my browser and browse through the directories. Browse via what? It would be entirely reasonable, not weird at all, if git.example/user/repo/ showed a list of branches and tags. And then it would actually be easier to reach git.example/user/repo/v3/ than to reach git.example/user/repo/master/v3/ The particular way github does directories isn't canonical. And if you wanted to clone the repo, you could clone a specific branch easily. When it comes to minor versions, you have to dig anyway to see the matching source under the current system.
  - paskozdilar 5y ago
    > Browse via what? Via whatever tool you have available. Most projects also have a download link or a clone command written, in case the remote repo doesn't support in-browser file listing, so you can download it and browse locally, without needing to checkout tag or whatever. > if you wanted to clone the repo, you could clone a specific branch easily. Unless I don't know how to clone a specific branch - in which case I need to learn about git branches, figure out how they work, and how to clone a specific branch, and how to go back to master etc. etc. etc. In contrast to just cloning the repo and browsing the v2/ directory.
    - Dylan16807 5y ago
      You blew past my main point, which is that if you go to browse an entire repo online, there's no reason that a v2/ directory will be easier to find than a v2/ branch, unless you're specifically assuming the site looks like github. > In contrast to just cloning the repo and browsing the v2/ directory. "just" cloning the repo? You gave this list of arduous steps for why cloning a tag is harder than browsing, but "just" cloning the repo still makes you do all but one of those steps! And if something is generating the clone command for you, it can add "-b". You don't need to know how git branches work. You definitely don't need to know how to go back to master.
      - paskozdilar 5y ago
        > You blew past my main point, which is that if you go to browse an entire repo online, there's no reason that a v2/ directory will be easier to find than a v2/ branch Absolutely not true. If you can "browse a repo", then by definition you can browse a directory inside a repo, so by definition you CAN do it. The option to choose a branch may or may not be there. > "just" cloning the repo? You gave this list of arduous steps for why cloning a tag is harder than browsing, but "just" cloning the repo still makes you do all but one of those steps! When you install a package from a remote repository, the go tool clones it to ~/go/pkg/mod/, so you can open it locally and browse through the code, without even touching git. So yeah, it is "just" cloning the repo. Also it works with any popular VCS, not just git.
- tsimionescu 5y ago
  > Personally, I love the fact that just by seeing the import path I know exactly which codebase is used. This is a bizarre statement. You only care to look at v4 or v7, not nor whether you're looking at v7.5.9 that is actually used in your program, or at v7.6.4 which you never upgraded to? > I also love the fact that I don't have to know s*t about git to use Go. Go is actually about the only language that forces you to know Git (or other sccs) to do dependency management. Just look at how horrible it is to develop and release multiple Go modules from the same repository, requiring specific tag names and who knows what else. Go mod is a terrible kludge and virtually every decision they've taken is simple only for the Go implementation team.
jrockway 5y ago
Git tags are completely orthogonal. When your main branch starts being v2, you only have to change go.mod to tack a v2 onto the end and keep your source code in the same place. "go get example.com/you/v2" will fetch exmaple.com/you from the main branch, read the go.mod file to see that it's v2, and continue. You don't have to actually create a v2 directory, or keep your old version in the main branch. (If you do tag releases, then "go get example.com/you/v2@v1.2.3" won't work, though.)
- Dylan16807 5y ago
  Well now I'm extra confused. If you do that, what command would you type to get "the most recent v1" now? How would it find it?

paskozdilar 5y ago

> it’s just a lazy solution: why on earth would I want to specify the version in the path? It's not a lazy solution, just opinionated. Personally, I love the fact that just by seeing the import path I know exactly which codebase is used. I don't have to open my go.mod, see which version I'm using, clone the repository, dig through the history to check out a specific tag and see what code is actually used in my program... I just open the repo in my browser and browse through the directories. There isn't a single system on earth that doesn't support directories! I also love the fact that I don't have to know s**t about git to use Go. If Go was to suddenly switch to git tags, not only would it break a massive amounts of existing code, but would basically force everyone to learn about git tags just to be able to see what code are they using, which would raise the amount of paperwork I have to fill in order to work on the thing I care about. Go is fundamentally against needless paperwork.

Dylan16807 5y ago
> I just open the repo in my browser and browse through the directories. Browse via what? It would be entirely reasonable, not weird at all, if git.example/user/repo/ showed a list of branches and tags. And then it would actually be easier to reach git.example/user/repo/v3/ than to reach git.example/user/repo/master/v3/ The particular way github does directories isn't canonical. And if you wanted to clone the repo, you could clone a specific branch easily. When it comes to minor versions, you have to dig anyway to see the matching source under the current system.
- paskozdilar 5y ago
  > Browse via what? Via whatever tool you have available. Most projects also have a download link or a clone command written, in case the remote repo doesn't support in-browser file listing, so you can download it and browse locally, without needing to checkout tag or whatever. > if you wanted to clone the repo, you could clone a specific branch easily. Unless I don't know how to clone a specific branch - in which case I need to learn about git branches, figure out how they work, and how to clone a specific branch, and how to go back to master etc. etc. etc. In contrast to just cloning the repo and browsing the v2/ directory.
  - Dylan16807 5y ago
    You blew past my main point, which is that if you go to browse an entire repo online, there's no reason that a v2/ directory will be easier to find than a v2/ branch, unless you're specifically assuming the site looks like github. > In contrast to just cloning the repo and browsing the v2/ directory. "just" cloning the repo? You gave this list of arduous steps for why cloning a tag is harder than browsing, but "just" cloning the repo still makes you do all but one of those steps! And if something is generating the clone command for you, it can add "-b". You don't need to know how git branches work. You definitely don't need to know how to go back to master.
    - paskozdilar 5y ago
      > You blew past my main point, which is that if you go to browse an entire repo online, there's no reason that a v2/ directory will be easier to find than a v2/ branch Absolutely not true. If you can "browse a repo", then by definition you can browse a directory inside a repo, so by definition you CAN do it. The option to choose a branch may or may not be there. > "just" cloning the repo? You gave this list of arduous steps for why cloning a tag is harder than browsing, but "just" cloning the repo still makes you do all but one of those steps! When you install a package from a remote repository, the go tool clones it to ~/go/pkg/mod/, so you can open it locally and browse through the code, without even touching git. So yeah, it is "just" cloning the repo. Also it works with any popular VCS, not just git.
tsimionescu 5y ago
> Personally, I love the fact that just by seeing the import path I know exactly which codebase is used. This is a bizarre statement. You only care to look at v4 or v7, not nor whether you're looking at v7.5.9 that is actually used in your program, or at v7.6.4 which you never upgraded to? > I also love the fact that I don't have to know s*t about git to use Go. Go is actually about the only language that forces you to know Git (or other sccs) to do dependency management. Just look at how horrible it is to develop and release multiple Go modules from the same repository, requiring specific tag names and who knows what else. Go mod is a terrible kludge and virtually every decision they've taken is simple only for the Go implementation team.

jrockway 5y ago

Git tags are completely orthogonal. When your main branch starts being v2, you only have to change go.mod to tack a v2 onto the end and keep your source code in the same place. "go get example.com/you/v2" will fetch exmaple.com/you from the main branch, read the go.mod file to see that it's v2, and continue. You don't have to actually create a v2 directory, or keep your old version in the main branch. (If you do tag releases, then "go get example.com/you/v2@v1.2.3" won't work, though.)

Dylan16807 5y ago
Well now I'm extra confused. If you do that, what command would you type to get "the most recent v1" now? How would it find it?