On Wednesday, October 12, 2016 at 2:04:19 AM UTC+2, Eric Johnson wrote:
My view is that the general case requires putting such metadata in a
> separate file for a package.
Yes, I agree with you that having multiple Go files with such comments
creates repetition (having to update multiple files) and forgetting to
update one of those makes it ambiguous which particular version is going to
> [...] after the current package management efforts nail down that metadata
Having been working with dependency management tools such `godep` and
`glide` would much prefer not to deal with any metadata files at all, with
their location, format, and naming conventions.
How about an implied metadata file when you specify package versions on the
`go get` command line but nowhere in source code or metadata files. Would
such a tradeoff work?
go get -u github.com/spf13/cobra:v1.10.0 \
This has a drawback that dependent packages are going to be installed as
their latest versions, so the ordering is important.
The reason for asking this question is that in recent months tools like
`glide` (https://github.com/Masterminds/glide) gained popularity and some
third-party packages require you to do `glide up` to populate it properly
in addition / instead of the regular `go get`. This means that for a
package that uses such a glided package, you'd need to create a Makefile
(or shell script) with a `glide up` and other non-`go` commands in it
(which is ugly).
> 2) Support for "go run" type usage that automatically fetches
> The second case seems possibly interesting, but implies a lot of mechanism
> for a rare case.
I agree, maybe then just `go get` then `go run`?
Thanks for your answer!
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.