Closed johanbrandhorst closed 4 years ago
I disagree. Keeping things automatically on git master can be preferable, especially at an early stage for a library like this. See https://github.com/purpleidea/mgmt/blob/master/docs/faq.md#why-arent-you-using-glide-godep-or-go-mod-for-dependency-management for one counter example.
Do you mean automatically updating upstream packages on every build? That can still be achieved with modules, indeed you could enforce it in CI.
On Mon, Sep 30, 2019 at 6:08 AM Johan Brandhorst notifications@github.com wrote:
Do you mean automatically updating upstream packages on every build? That can still be achieved with modules, indeed you could enforce it in CI.
By using go.mod you actually store the sha1 hashes in git in that file which is IMHO a mistake. Cat the file and you'll see what I mean.
I'm not sure what you mean by that. It will store all versions of the dependencies you've ever used. It doesn't enforce the use of that version, that is what the constraints in go.mod
are for.
You can use go get <library>@master
followed by git diff --exit-code
to enforce use of latest versions in CI.
@johanbrandhorst Sorry, I should have been more clear. I was just replying quickly. If you look here:
https://github.com/varlink/go/pull/12/files#diff-f949e2d81c8076ebbf8af38fcbb72c1fR7
You'll see a cryptographic hash of whatever version the user had that dependency of when it was created. If that repo has a newer git master release, then this is automatically out of date. If you want to force a specific version, then use a git submodule in vendor/ and it will be guaranteed. Anything else that isn't in there and you want to always be "up-to-date" with git master, you omit.
HTH
I see what you mean, but I think it's a nice courtesy to downstream users to explicitly expose the dependant package versions that were used when the CI tests were run. As I said, we can still allow, and even enforce that the latest versions of upstream dependencies are used.
I think it's a nice courtesy to downstream users to explicitly expose the dependant package versions that were used when the CI tests were run
I agree that this should be done, but only for tagged releases. I actually haven't implemented this yet in https://github.com/purpleidea/mgmt/ (my project) but it's something I'd like to do soon. Basically before tagging a release I'd run something like make savemod
which would run a script and store all the deps (perhaps as go.mod format) in a file and put it into releases/$version ... And then commit that. If you wanted a specific version you could run a similar restore script to pull it out. It would need a bit of shell glue because upstream golang is obtuse about this. We should absolutely NOT put any go.mod file in the root to be used by default. HTH
Advising against using go modules would pretty much break all workflows of projects I'm working on or interact with.
Ultimately, it depends on what individual projects want to do and how they intend to be used but I don't find it helpful to suggest using something non-default and non-standardized that even doesn't exist. Go mod does more than pulling in code and more and more people expect projects to provide a module - which I assume is the intention of this issue.
OK, I didn't expect this must opposition to the idea. I think you'll find that this is going to be a somewhat controversial opinion on the wider community, which will increase friction for users wanting to contribute to this library, but I'm not here to tell you how to run your project. I would encourage you to raise your concerns with the Go project itself though. I think it would be best for the ecosystem if we all agree it is the best way forward.
On Mon, Sep 30, 2019 at 6:34 AM Johan Brandhorst notifications@github.com wrote:
OK, I didn't expect this must opposition to the idea. I think you'll find that this is going to be a somewhat controversial opinion on the wider community, which will increase friction for users wanting to contribute to this library, but I'm not here to tell you how to run your project. I would encourage you to raise your concerns with the Go project itself though. I think it would be best for the ecosystem if we all agree it is the best way forward.
Concerns have been raised by others, which is why vendor/
is still
supported. There's an FAQ about this, I can find it if you like.
Sadly, go.mod
has a lot of adoption because many users are afraid of
git submodules. A bunch of people do use them, and it's the more
technically correct solution if you aren't spreading FUD around git.
I can't spend any more time on this. I think I've made my point. Varlink isn't even at a 1.0 where it should even be considered stable. Cheers
It would be good to have a
go.mod
file so that dependants of this repo can resolve transitive dependencies correctly. Even for packages that only use the standard library this is a best practice.