go mod vendor, description, how?

[fge...@gmail.com]

Hi,

assuming GO111MODULE=on.
I don't want to publish anything, anywhere.

Beside the main package, I want to put functionality into other new
packages as well.
Could somebody share the workflow to do _only_ that?
Where can I read about the correct incantations?

To organize the source files on
https://golang.org/ref/mod#go-mod-vendor this is not enough
information for me:
"The go mod vendor command constructs a directory named vendor in the
main module's root directory that contains copies of all packages
needed to support builds and tests of packages in the main module. "

How, does the "go mod vendor" command construct the vendor directory?
Where does it copy the files from?
How is the copy instructed (what to copy, what not to copy)?

thanks!

[Brian Candler]

It depends what you're trying to achieve. In the simplest case, is this all one project in one repo, but broken into packages?  In that case,  you can just "go mod init" in the top-level directory, and then you create your dependent packages in subdirectories (without go.mod files).

Here I just used "go mod init foo", "mkdir bar", and created main.go and bar/greet.go

==> go.mod <==

module foo

go 1.16

==> main.go <==

package main

import (

"fmt"

"foo/bar"

)

func main() {

fmt.Println(bar.Greeting)

}

==> bar/greet.go <==

package bar

const Greeting = "Hello world!"

$ go run .

Hello world!

You don't need to vendor anything unless you're importing third-party code from other repositories.

[Volker Dobler]

Probably you are overthinking it. Start like this

    go mod init me.nil/project

It doesn't matter whether you want to publish your project or not you must

start with a module and a proper name including a dot and a slash doesn't

harm and avoids several problems. Of course you also could name it

github.com/yourname/yourproject. If you do not want to publish it, it

really doesn't matter.

Add a main.go an make packages to your liking:

    vi main.go

    mkdir foo

    vi foo/foo.go

And so on. There is _no_ need for go mod vendor at all, especially not

if you do not want to publish your project.

V.

[Brian Candler]

You don't need to vendor anything unless you're importing third-party code from other repositories, AND you don't want them to be fetched dynamically.

[Manlio Perillo]

Il giorno martedì 6 aprile 2021 alle 09:47:18 UTC+2 Gergely Födémesi ha scritto:

Hi,

assuming GO111MODULE=on.
I don't want to publish anything, anywhere.

If you don't want to publish anything, you can use a reserved domain in your module path; as an example:

gergely.localhost, or gergely.local (the latter will require adding the host to /etc/hosts).

Beside the main package, I want to put functionality into other new
packages as well.
Could somebody share the workflow to do _only_ that?
Where can I read about the correct incantations?

When fetching external modules to resolve your module dependencies, the go tool will assume the module path is an URL, fetching the package using the network.

One exception is when using the Go module proxy (GOPROXY); here the module path is generic URI.

There are 4 solutions for supporting local modules:

1. Using the replace directive in go.mod

2. Using a custom Go Proxy that resolves a Go module to a vcs repository on your filesystem.

     I don't know if Athens support local modules.

3. Implement the go get protocol, resolving modules to a vcs repository on your filesystem.

    I have a working implementation but currently is not published.

4. Configure git to resolve an HTTP resource to a local filesystem resource:

      go env -w GOPRIVATE="gergely.local"

      git config --global "url.file://$root/gergely.local".insteadOf "https://gergely.local"

    where $root is the directory containing the gergely.local directory.

    If your modules are inside GOPATH, then root is $gopath/src

Regards

Manlio

[fge...@gmail.com]

On 4/6/21, Volker Dobler <dr.volke...@gmail.com> wrote:
> Probably you are overthinking it.

> ...

Thank you all for your replies!
I did overthink.

When https://blog.golang.org/using-go-modules [part1-5] were
published, I've read all of them, some parts several times. It helped
with code migrations.
Still my question remains: assuming almost exactly a decade of using
go with GOPATH how should have I found the information in your
replies?

+1 question: what's the thing with the dot requirement in the module
path? It's probably not a requirement, but than again, why is it
casually mentioned in some module relevant replies?

I know good terse documentation is much harder to write, than a good
complete documentation. I've tried to read https://golang.org/ref/mod
(~24k words), but I was not strong enough and gave up. The go
programming language specification is ~28k words, I've read it a few
times.

Are we trying the document similar complexity? If yes, I believe this
has implications for the future use of modules, if no, there is room
for improvement. What do you think?

Thanks again for your time!