Where is the version number for a golang module declared?

[Dean Schulze]

The various examples I've seen for using golang modules describe how to specify the version number of a dependency, but I haven't seen how to declare the version number of a module.  Some examples suggest adding a /vN to the import path where N is the major version number, but don't say anything about the minor version numbers.

Are versioned modules supposed to have separate directories?

An example of how to specify the version number of a go module would be greatly appreciated.

[Dean Schulze]

This blog entry uses git tags.  It didn't mention branches.  Are tags the only way to declare a version number?

Also, what if my git repo is local to my laptop?  I'd think I should still be able to publish versioned modules to my local GOPATH from my local git repo.

[Tamás Gulácsi]

AFAIK tags are for concrete version (vMajor.Minor.Patch), branches and a subdirectory for maintaining different major versions concurrently.

[Bryan C. Mills]

On Tuesday, March 10, 2020 at 5:47:45 PM UTC-4 dean.w....@gmail.com wrote:

This blog entry uses git tags.  It didn't mention branches.  Are tags the only way to declare a version number?

Yes, tags are the way to declare a version.

Generally branches represent ongoing development: further commits may be added without changing the branch name.

In contrast, each version of a Go module must refer to one specific, unchanging copy of the code.

(That is important both for security and for reproducibility.)

Also, what if my git repo is local to my laptop?  I'd think I should still be able to publish versioned modules to my local GOPATH from my local git repo.

 

See https://golang.org/issue/28835, but in general we do not expect users to need version selection for modules that are not published beyond a single host.

(But note that you can always set up a local HTTP server using the remote import path protocol, and use a local DNS entry and the GOPRIVATE environment variable to tell the Go command where to find the repo.)

[Dean Schulze]

Well, that was going to be my next question (how do I install a module from a local git repo or directory).

If I understand you correctly go modules require a remote git repo, even if they are used only one machine.  That should be made clear in the docs.

Modules get cached locally in $GOPATH/pkg/mod, but in my module directory of I do

    go install lib/conf.reader.go

it completes without errors, but I don't get a binary or source code file anywhere under $GOPATH/pkg/mod (or anywhere else I can see).

Does go install work differently with modules?

[Bryan C. Mills]

`go install` does the same thing that it always has: it installs compiled binaries and object files, not module source code. (A module may contain multiple packages and multiple binaries.)

See https://blog.golang.org/using-go-modules for a higher-level introduction, and note that https://golang.org/doc/code.html is now written for module mode rather than GOPATH mode.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/eqEzMk5QFuk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2eb95d66-b5e5-4640-a6cc-529189fe38ed%40googlegroups.com.

[Dean Schulze]

Well here's what I get in my module with a single directory with a single file with a single package called lib:

$ go install lib

can't load package: package lib is not in GOROOT (/home/dean/bin/go1.14.linux-amd64/go/src/lib)

If I add the pwd to my GOPATH (the way things worked before modules) I get:

$ go install lib

$GOPATH/go.mod exists but should not

If I remove the go.mod file and give it the relative path to a source file it works but doesn't install anything:

$ go install src/lib/conf.reader.go 

On Wednesday, March 11, 2020 at 12:43:01 PM UTC-6, Bryan C. Mills wrote:

`go install` does the same thing that it always has: it installs compiled binaries and object files, not module source code. (A module may contain multiple packages and multiple binaries.)

See https://blog.golang.org/using-go-modules for a higher-level introduction, and note that https://golang.org/doc/code.html is now written for module mode rather than GOPATH mode.

On Wed, Mar 11, 2020 at 2:33 PM Dean Schulze <dean.w...@gmail.com> wrote:

Well, that was going to be my next question (how do I install a module from a local git repo or directory).

If I understand you correctly go modules require a remote git repo, even if they are used only one machine.  That should be made clear in the docs.

Modules get cached locally in $GOPATH/pkg/mod, but in my module directory of I do

    go install lib/conf.reader.go

it completes without errors, but I don't get a binary or source code file anywhere under $GOPATH/pkg/mod (or anywhere else I can see).

Does go install work differently with modules?

On Wednesday, March 11, 2020 at 9:22:46 AM UTC-6, Bryan C. Mills wrote:

On Tuesday, March 10, 2020 at 5:47:45 PM UTC-4 dean.w....@gmail.com wrote:

This blog entry uses git tags.  It didn't mention branches.  Are tags the only way to declare a version number?

Yes, tags are the way to declare a version.

Generally branches represent ongoing development: further commits may be added without changing the branch name.

In contrast, each version of a Go module must refer to one specific, unchanging copy of the code.

(That is important both for security and for reproducibility.)

Also, what if my git repo is local to my laptop?  I'd think I should still be able to publish versioned modules to my local GOPATH from my local git repo.

 

See https://golang.org/issue/28835, but in general we do not expect users to need version selection for modules that are not published beyond a single host.

(But note that you can always set up a local HTTP server using the remote import path protocol, and use a local DNS entry and the GOPRIVATE environment variable to tell the Go command where to find the repo.)

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/eqEzMk5QFuk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to golan...@googlegroups.com.

[Volker Dobler]

The go tool works well if you use package import path

as arguments.

On Wednesday, 11 March 2020 20:49:53 UTC+1, Dean Schulze wrote:

Well here's what I get in my module with a single directory with a single file with a single package called lib:

To be concrete let the module name be dean.schulz/awsome

and containing one folder lib containing package lib.

With this setup the import path of this package lib is

   dean.schulz/awsome/lib 

$ go install lib

can't load package: package lib is not in GOROOT (/home/dean/bin/go1.14.linux-amd64/go/src/lib)

Try cd' _into_ the lib folder and either

    $ go install

    $ go install  dean.schulz/awsome/lib

 

If I add the pwd to my GOPATH (the way things worked before modules) I get:

$ go install lib

$GOPATH/go.mod exists but should not

It is either GOPATH or go modules. Don't try mixing stuff. 

If I remove the go.mod file and give it the relative path to a source file it works but doesn't install anything:

$ go install src/lib/conf.reader.go 

Again: Most subcommands of the go tool work best if

invoked with the "import path" of a package. The import

path with modules is formed like this:

    <full-module-name>/<relative-path-to-package-folder-inside-module-root>

What works very well too is cd'ing into the folder and calling

build, install, test, etc _without_ any arguments.

V.

[Benjamin]

Go programming language has no version mechanism.
Like java jar files that contains class files.

If you want to use special version, the version can be included in the import path

> On Mar 11, 2020, at 13:32, Tamás Gulácsi <tgula...@gmail.com> wrote:
>
> AFAIK tags are for concrete version (vMajor.Minor.Patch), branches and a subdirectory for maintaining different major versions concurrently.
>

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ac8b47d5-3b5f-421d-a577-f7861281af84%40googlegroups.com.

[Wojciech S. Czarnecki]

Dnia 2020-03-11, o godz. 08:22:46
"'Bryan C. Mills' via golang-nuts" <golan...@googlegroups.com> napisał(a):

> (But note that you can always set up a local HTTP server using the remote

> import path <https://golang.org/cmd/go/#hdr-Remote_import_paths> protocol,

> and use a local DNS entry and the GOPRIVATE environment variable to tell
> the Go command where to find the repo.)

The very need for such a workaround tells that something is severely broken.

1. set up local server just to serve what GOPATH provided seamlessly

2. tinker with your /etc/hosts or c:\Windows\System32\Drivers\etc\hosts or /private/etc/hosts.
Do it **every time** you want to work locally on a module from other domain.

3. Reconfigure hosts and your local web server **every time** you want to work locally
on a next module. Keep all these configs forever, because you may need to maintain your
patches

4. do not forget to set up GOPRIVATE, otherwise you will leak to the outer world
rinse and repeat on any host you do tests etc

We need to dance this quadrille because go tools won't look at the
go.mod.local (https://github.com/golang/go/issues/26640)

Unfortunately "go.mod.local" was not invented at Google, so chances we
would ever have sane G-independent setup are miniscule now. Mind also
that GOPATH is now led to the guillotine, to force all this "local server /
crafted hosts / GOPRIVATE setup" fun on everyone not willing to share
her development setup with the big G.

my ¢2

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Nick]

Hi Wojciech,

> We need to dance this quadrille because go tools won't look at the
> go.mod.local (https://github.com/golang/go/issues/26640)
>
> Unfortunately "go.mod.local" was not invented at Google, so chances we
> would ever have sane G-independent setup are miniscule now. Mind also
> that GOPATH is now led to the guillotine, to force all this "local server /
> crafted hosts / GOPRIVATE setup" fun on everyone not willing to share
> her development setup with the big G.

Forgive my ignorance, but why aren't gohack and replace statements
in the go.mod file perfectly good replacements for these use cases?
I get the feeling I'm missing something...

I agree that anything that penalises people for not using Google
services is problematic, but I don't see how that's happening here.

Nick

[Wojciech S. Czarnecki]

Dnia 2020-03-12, o godz. 19:11:48
Nick <ni...@njw.name> napisał(a):

> Forgive my ignorance, but why aren't gohack and

> in the go.mod file perfectly good replacements for these use cases?
> I get the feeling I'm missing something...

> why aren't gohack

Gohack is an invaluable tool to hack around without need to manual
edits of go.mod once a couple of minutes. Note the "hack" in its name,
though ;). Note also, that this exact mechanics used for modules could
work over repos staying in the GOPATH. For way less code and effort
that went into centralized zipfiles solution.

> and replace statements in the go.mod

Explained in pointed to go.mod.local issue: tl;dr – go.mod changes
intended for local tinkering may inadvertently end in the CI pipe.
It is cumbersome to do all that dance just to tinker in an early stage
of minting something new.

> I agree that anything that penalises people for not using Google
> services is problematic, but I don't see how that's happening here.

TL;DR - IMO, Go community is now being led into the technically unsound
dependency off G/cloud infrastructure. Escape paths, still present yet, are
full of obstacles and are easy to close in the future, would G wish so.

LR:
Offline setup is still possible, but now it is cumbersome and full of traps.
We somehow went from the self-contained local tree of dependencies'
full source – gathered from any of supported VCS repo – to the cloud
infrastructure managed by G from where zipfiles (hello npm!) are
downloaded then checked against G owned database.

In the case of godoc.org sunset [1], it was not even planned for you to
run local docs server at all (G backpedaled on this a bit due to a backslash
from the community [2]). Still it is G who can decide whether your code
deserves to be listed at go.pkg.dev [3]. It now is a well lubricated slope
to some future "notarization / approval" process.

I am an old frog and I think I can discern whether I am being cooked
even if pot I am in is advertised as a comfortable warming device.

[1] https://blog.golang.org/pkg.go.dev-2020
[2] https://github.com/golang/go/issues/36747
[3] https://github.com/golang/go/issues/36840

PS. I do not blame the technical team, as IMO this was a "business decission"
in upper echelons of Google what dev-team as a G employees, must obey.

> Nick