Hi, Manlio. Thank you for your reply!
The project is an application, however, I’m planning to write the underlying components so they are reusable, so they can be leveraged elsewhere. Since I will be using the packages to build an app, I need to make sure the builds are reproducible. ☺ I had a very helpful email exchange with Dave Cheney, and he suggested gb + semver. With the current lack of convergence on go package versioning/dependency management, it seems wise to me to follow his recommendation, since he is one of the Go gurus. Hey, go+ is a cool script! Thanks for sharing! I’m finding out (the hard way) how to deal with cyclic dependencies, so package management has become really important to me. Question: is it possible for gb to vendor a specific version of a package? If I have a dependency on package xyz version 2.4, can I configure gb to know that I need xyz version 2.4, or do I have to deal with that separately (e.g. in a Makefile that calls git)? I’m a Go newbie, and am making some notes about learning Go. I’ve put them here: https://github.com/jeffkayser2/learningGo/wiki It will not contain much of interest for experienced Go programs, but might help some other newbies. Items 6 and 7 have info I've gleaned from Internet and Dave Cheney about package management, dependency management, package versioning, cyclic dependencies, etc. Jeff Kayser Jibe Consulting | Managing Principal Consultant 5000 Meadows Rd. Suite 300 Lake Oswego, OR 97035 O: 503-517-3266 | C: 503.901.5021 jeff.kay...@jibeconsulting.com From: Manlio Perillo [mailto:manlio.peri...@gmail.com] Sent: Sunday, February 05, 2017 4:03 AM To: golang-nuts <golang-nuts@googlegroups.com> Cc: Jeff Kayser <jeff.kay...@jibeconsulting.com>; jeffkays...@gmail.com Subject: Re: Go package/version management, vendoring, dep, gb, etc... Il giorno domenica 5 febbraio 2017 06:35:18 UTC+1, jeffk...@gmail.com ha scritto: I can’t seem to converge on a decent package/version management scheme. I asked Dave Cheney, and he recommended that I email this list. I’ve written a Go project. I started with a directory tree like this: $GOPATH/src/project/objects/agent_v1/agent_v1.go (import “project/objects/agent_v1”) $GOPATH/src/project/objects/customer_v1/customer_v1.go (import “project/objects/customer_v1”) Etc. I know that I needed to be able to support different versions of my objects, so that is the directory structure I started using. Is your project a package (for other developers to use) or an application? What I’m looking for: A solution that will: a) make builds reproducible. If your project is a package, usually (IMHO) you should forget about making builds reproducible. This is responsibility of the develper that uses your package in his project. b) use SemVer 2.0.0 versioning. You can just add tags or branches on your git repository following, as an example, the convention proposed by Dave Cheney. > [...] e) use the standard Go tooling as much as possible. Only use other tooling where the standard Go tooling won’t work for package/version management. For web applications I use the layout proposed by Dave Cheney in db (but this layout seems to be used by other projects, too). I use gb build when building, since it is convenient, but I use standard go tools for everything else, using this script named go+" #!/bin/sh # Execute the go tool for the current project. # The project should have the layout as defined by the gb tool. GOPATH="$PWD:$PWD/vendor" GOBIN="$PWD/bin" go $@ When importing dependencies I use gb vendor fetch, but for some cases I just clone the repository inside vendor/src/. If your project is a package you can import the dependency in a vendor directory. There are some example in the Go standard library. However you should be careful, since some packages can not be imported multiple time (like the SQL drivers). Manlio Disclaimer: This electronic message may contain information that is Confidential or legally privileged. It is intended only for the use of the individual(s) and entity named in the message. If you are not an intended recipient of this message, please notify the sender immediately and delete the material from your computer. Do not deliver, distribute or copy this message and do not disclose its contents or take any action in reliance on the information it contains. -- 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.
