On Monday, 6 February 2017 15:03:03 UTC+11, Jeff Kayser wrote: > > 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?
Yes > 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)? > No gb only cares what is in your project (that includes vendor/src). How you, as the project owner, do this is your problem. As long as all the packages that are imported by your program are represented, gb doesn't care. You can do this manually, by forking code into vendor/src, you can use git submodules if your politics permit, or you could use the gb-vendor plugin. > > 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....@jibeconsulting.com <javascript:> > > > > From: Manlio Perillo [mailto:manlio....@gmail.com <javascript:>] > Sent: Sunday, February 05, 2017 4:03 AM > To: golang-nuts <golan...@googlegroups.com <javascript:>> > Cc: Jeff Kayser <jeff....@jibeconsulting.com <javascript:>>; > jeffk...@gmail.com <javascript:> > 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.
