Re: [go-nuts] Re: go mod vendor, description, how?
On 4/6/21, Volker Dobler 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! -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2BctqrosXn1PhdudK1HNGJEeOS8F0EaEuKfC_VA4pnBRRArOsQ%40mail.gmail.com.
[go-nuts] Re: go mod vendor, description, how?
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 -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e5ded646-f0fe-4c11-ac59-b94923f9af18n%40googlegroups.com.
[go-nuts] Re: go mod vendor, description, how?
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. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1b10ca07-5c45-45d3-a1db-d17c9c5ec664n%40googlegroups.com.
[go-nuts] Re: go mod vendor, description, how?
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. On Tuesday, 6 April 2021 at 09:47:18 UTC+2 Gergely Födémesi wrote: > 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! > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/26800666-75d6-4086-b850-18290407aa66n%40googlegroups.com.
[go-nuts] Re: go mod vendor, description, how?
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.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/f4617546-35b6-4574-b539-b11f5f59b3c5n%40googlegroups.com.
