4 ms·

As a reminder to Go package maintainers: Please tag your releases. Many companies* use http://glide.sh http://glide.sh for package management. By default, it gr

As a reminder to Go package maintainers: Please tag your releases. Many companies* use http://glide.sh http://glide.sh for package management. By default, it grabs the last tagged build, not master. We've encountered broken code.google.com links on the last tagged release, and it's not a great experience to override to a hash. * e.g. Uber uses it https://github.com/uber/tchannel-go https://github.com/uber/tchannel-go

ocdtrekkie 10y ago
As a note: "Uber" is not a good citation for "Many companies". ;) But I totally lament the lack of use of tagged releases on GitHub. Sometimes I am looking for versions before some things but after others, for some reason, and it can be very hard to find in a commit list where the code was stable/functional. Depending on the repository, you often can't trust current master to be stable code either.
- philip1209 10y ago
  Totally fair - my point was that users are beyond just early adopters. Glide doesn't keep a good record of public users.
GFK_of_xmaspast 10y ago
This looks like a failure in the go package management methodology.
- philip1209 10y ago
  Go has no package management philosophy. It works well if you're using Bazel/Blaze. Not so well if you're grabbing a library off of Github.
  - deleted 10y ago
    [deleted]
XorNot 10y ago
I don't like glide. It manages to recreate the pain of package installation in every other language. The thing I really love about the golang vendor/ approach is that the dumbest possible way just works - the code is all there. Glide gets pretty far away from that. The perfect model (or one which would produce the prettiest git diffs) would probably be a tool which kept the actual vendor'd packages under their own branch forks in the same git repo and checked them all out when you need them, just so vendoring changes wouldn't wind up being huge source tree diffs).
- nulltype 10y ago
  I've seen the complaint about huge diffs a few times. Why not just exclude vendor directories from the diff?
  - XorNot 10y ago
    Can Github (and Github Enterprise) do this automatically? Basically, like most problems, the issue is that it interferes with a very common interface rather then being a real problem. If I could have PRs by default fold vendor/ folders for me, then yeah - problem solved more or less.

ocdtrekkie 10y ago

As a note: "Uber" is not a good citation for "Many companies". ;) But I totally lament the lack of use of tagged releases on GitHub. Sometimes I am looking for versions before some things but after others, for some reason, and it can be very hard to find in a commit list where the code was stable/functional. Depending on the repository, you often can't trust current master to be stable code either.

philip1209 10y ago
Totally fair - my point was that users are beyond just early adopters. Glide doesn't keep a good record of public users.

GFK_of_xmaspast 10y ago

This looks like a failure in the go package management methodology.

philip1209 10y ago
Go has no package management philosophy. It works well if you're using Bazel/Blaze. Not so well if you're grabbing a library off of Github.
- deleted 10y ago
  [deleted]

XorNot 10y ago

I don't like glide. It manages to recreate the pain of package installation in every other language. The thing I really love about the golang vendor/ approach is that the dumbest possible way just works - the code is all there. Glide gets pretty far away from that. The perfect model (or one which would produce the prettiest git diffs) would probably be a tool which kept the actual vendor'd packages under their own branch forks in the same git repo and checked them all out when you need them, just so vendoring changes wouldn't wind up being huge source tree diffs).

nulltype 10y ago
I've seen the complaint about huge diffs a few times. Why not just exclude vendor directories from the diff?
- XorNot 10y ago
  Can Github (and Github Enterprise) do this automatically? Basically, like most problems, the issue is that it interferes with a very common interface rather then being a real problem. If I could have PRs by default fold vendor/ folders for me, then yeah - problem solved more or less.