search

varlink / go

Golang implementation of the Varlink protocol
https://godoc.org/github.com/varlink/go/varlink
Apache License 2.0
55 stars 57 forks source link

Add go.mod file #11

Closed johanbrandhorst closed 4 years ago

johanbrandhorst commented 4 years ago

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.

purpleidea commented 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.

johanbrandhorst commented 4 years ago

Do you mean automatically updating upstream packages on every build? That can still be achieved with modules, indeed you could enforce it in CI.

purpleidea commented 4 years ago

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.

johanbrandhorst commented 4 years ago

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.

purpleidea commented 4 years ago

@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

johanbrandhorst commented 4 years ago

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.

purpleidea commented 4 years ago

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

vrothberg commented 4 years ago

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.

johanbrandhorst commented 4 years ago

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.

purpleidea commented 4 years ago

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