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 
be installed. 
 

> [...] after the current package management efforts nail down that metadata 
> file.
>
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 \
          github.com/spf13/viper:v0.10.0 \
          github.com/pelletier/go-toml:v0.3.4


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 
> dependencies....
>
> 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 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to