Re: [go-nuts] New Modules and git clones

2018-11-16 Thread Russel Winder
On Thu, 2018-11-15 at 14:20 +, Paul Jolly wrote: […] > > The update rewrites non-canonical version identifiers to semver form, > > so A's v1 becomes v1.0.0 and E's dev becomes the pseudo-version for the > > latest commit on the dev branch, perhaps v0.0.0-20180523231146- > > b3f5c0f6e5f1. It

Re: [go-nuts] New Modules and git clones

2018-11-15 Thread Paul Jolly
> The `dev` in that documentation is intended to be a branch name. If that > module doesn't actually have a branch named `dev`, it won't work. Thanks for humouring my stupidity :) Because as if to reinforce the fact that I've never seen that help document, I've also successfully demonstrated

Re: [go-nuts] New Modules and git clones

2018-11-15 Thread thepudds1460
Russel, Just two add a quick doc reference: The general capability being discussed here is called "module queries". This section of the doc is probably worth a quick read or re-read: https://golang.org/cmd/go/#hdr-Module_queries Module queries provide a fair amount of flexibility, and allow

Re: [go-nuts] New Modules and git clones

2018-11-15 Thread Paul Jolly
> > The `dev` in that documentation is intended to be a branch name. If that > > module doesn't actually *have* a branch named `dev`, it won't work. Thanks, Bryan. > ... > > Hopefully there is a way of this getting updated as master/HEAD gets more > commits. Not automatically, no. go get

Re: [go-nuts] New Modules and git clones

2018-11-15 Thread Russel Winder
On Wed, 2018-11-14 at 15:36 -0800, 'Bryan Mills' via golang-nuts wrote: […] > The `dev` in that documentation is intended to be a branch name. If that > module doesn't actually *have* a branch named `dev`, it won't work. […] Bingo. I put require ( github.com/jamalsa/qml master

Re: [go-nuts] New Modules and git clones

2018-11-14 Thread 'Bryan Mills' via golang-nuts
On Wednesday, November 14, 2018 at 2:26:07 PM UTC-5, Paul Jolly wrote: > > > > Can you point us at the documentation you're referring to here, > please? > > > > go help go.mod > > Thanks - it's honestly the first time I've a) read that help document > or b) seen the dev version format. I

Re: [go-nuts] New Modules and git clones

2018-11-14 Thread Russel Winder
On Wed, 2018-11-14 at 19:25 +, Paul Jolly wrote: > > > Can you point us at the documentation you're referring to here, please? > > > > go help go.mod > > Thanks - it's honestly the first time I've a) read that help document > or b) seen the dev version format. I also can't find any tests >

Re: [go-nuts] New Modules and git clones

2018-11-14 Thread Paul Jolly
> > Can you point us at the documentation you're referring to here, please? > > go help go.mod Thanks - it's honestly the first time I've a) read that help document or b) seen the dev version format. I also can't find any tests covering its usage. Please can you raise an issue about the use of

Re: [go-nuts] New Modules and git clones

2018-11-14 Thread Paul Jolly
> I recommend letting the go tool handle this. Leave the dependency out of the > go.mod file entirely. Run go build as normal, and it will automatically > determine the version strings for the dependencies and insert them into your > go.mod for you. This won't work because per the original

Re: [go-nuts] New Modules and git clones

2018-11-14 Thread Russel Winder
On Wed, 2018-11-14 at 10:10 -0600, Kyle Wood wrote: > I recommend letting the go tool handle this. Leave the dependency out of > the go.mod file entirely. Run go build as normal, and it will automatically > determine the version strings for the dependencies and insert them into > your go.mod for

Re: [go-nuts] New Modules and git clones

2018-11-14 Thread Russel Winder
On Wed, 2018-11-14 at 12:31 +, Paul Jolly wrote: > > The documentation implies that I can use "dev" as the > > version number in the go.mod file for this situation > > Can you point us at the documentation you're referring to here, please? > > Thanks Type go help go.mod part way down,

Re: [go-nuts] New Modules and git clones

2018-11-14 Thread Kyle Wood
I recommend letting the go tool handle this. Leave the dependency out of the go.mod file entirely. Run go build as normal, and it will automatically determine the version strings for the dependencies and insert them into your go.mod for you. On Wed, Nov 14, 2018 at 5:43 AM Russel Winder wrote:

Re: [go-nuts] New Modules and git clones

2018-11-14 Thread Paul Jolly
> The documentation implies that I can use "dev" as the > version number in the go.mod file for this situation Can you point us at the documentation you're referring to here, please? Thanks -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

SV: [go-nuts] New Modules and git clones

2018-11-14 Thread Michael Banzon
I have used the ”v0.0.0” as the version number – it seem to work. /M Fra: Russel Winder<mailto:rus...@winder.org.uk> Sendt: 14. november 2018 12:44 Til: GoLang_Nuts<mailto:golang-nuts@googlegroups.com> Emne: [go-nuts] New Modules and git clones I am giving the module system in Go 1.

[go-nuts] New Modules and git clones

2018-11-14 Thread Russel Winder
I am giving the module system in Go 1.11.2 a whirl to get projects out of the GOPATH environment. The dependencies include ones that have no tagged versions in the Git repositories. The documentation implies that I can use "dev" as the version number in the go.mod file for this situation. However,