Re: [go-nuts] How to automatically embed module name from go.mod into executables?

Good news! The main package path, the containing module, and all of the dependencies and their versions are already embedded in Go executables. You can read that info with `go version -m path/to/exe`. $ go install golang.org/x/tools/cmd/stringer@latest $ go version -m ~/go/bin/stringer /Users/jay

Re: [go-nuts] Does the module name have to include the repo name when you publish a Go module?

The module path needs to be part of a valid URL, but it doesn't have to be the same as the repository URL. That's what my golang.org/x/mod example was meant to demonstrate. The repository is hosted on a different domain. On Tue, Sep 7, 2021 at 1:05 PM Dean Schulze wrote: > Your first paragraph s

Re: [go-nuts] Does the module name have to include the repo name when you publish a Go module?

The module path doesn't need to match the repo URL, but if other modules depend on your module, then the go command needs to be able to find your repository given your module path. The lexical constraints for module paths are documented at https://golang.org/ref/mod#go-mod-file-ident. In short, th

Re: [go-nuts] Leading dash invalid in test filename inside module

You're exactly right, the proxy is still in the process of migrating to Go 1.17. It should be done in the next day or two, at which point it should be able to fetch this version. In the mean time, you can work around it by setting GOPRIVATE= github.com/benhoyt/goawk

Re: [go-nuts] go.sum security error

Ideally `go mod verify` would help in this situation, but it only compares the contents of go.sum against the module cache, and if they're consistent with each other but not the outside world, it won't report an error. I've opened #47752 for this. On Tue

Re: [go-nuts] go.sum security error

I think the problem is in go.sum. If it already contains an incorrect sum for a module version, the go command will report a security error when downloading that version (if the download has a different sum) or when using that version (if the cached version had a different sum that appeared to be v

Re: [go-nuts] Go mod ignoring project sub-modules

If you are using submodules, the best way to do that is to treat each modules as a separately versioned, releasable unit. So each module has a "require" directive for other modules it needs at the minimum usable version (managed with 'go get' or 'go mod tidy'). You can tag versions for each submodu

[go-nuts] Share your thoughts about Go’s built-in fuzzing

Hi, earlier this year the Go Fuzzing Team released a public preview of built-in fuzzing support in Go. Now that folks have had some time to experiment with it, we’d love to learn more about what’s working well and what could be improved. If you’ve tried out Go’s

Re: [go-nuts] Go mod ignoring project sub-modules

Hi Nic, This is actually working as intended, though I don't think we've adequately documented it. I've sent CL 342531 to mention this in the reference documentation. In short though, files in a subdirectory that contains a go.mod file are c

Re: [go-nuts] go.sum security error

This doesn't seem like a problem with Go versions. The security error is correct. It looks like the module author tagged v1.1.1 with this go.mod file then changed the tag to point to a different commit with this file

Re: [go-nuts] `go list` across multiple modules?

Despite what the blog post says, Go 1.17 won't drop support for GO111MODULE or GOPATH mode. It will be more or less the same as GOPATH mode. We'll continue to work on these issues and others that are blocking people from migrating. I apologize for the slow progress–we have a lot going on. On Wed,

Re: [go-nuts] Re: go install an/import/path@revision and /vendor in Go 1.16

Indeed, this should be better documented. I've mailed CL 340509 to mention in a couple places in /ref/mod that vendor directories are omitted from zip files. On Fri, Aug 6, 2021 at 3:55 AM Brian Candler wrote: > On Friday, 6 August 2021 at

Re: [go-nuts] Showing effective replace in go modules

The go command only applies replace directives from the main module's go.mod file. In this example, replace directives in your module B would be applied, but replace directives in A (or any other dependency) would be ignored. This is important for avoiding conflicts that can't easily be resolved (f

Re: [go-nuts] how to purge invalid tags from GOPROXY?

As Dan mentioned, the version containing the retractions must be the highest version, so you'd need to tag v1.4.3 or higher. If that version retracts itself, it won't appear in the version list either. On Thu, Jul 1, 2021 at 1:58 AM Sebastien Binet wrote: > Hi Jay, > > On Thu Jul 1, 2021 at 00:4

Re: [go-nuts] how to purge invalid tags from GOPROXY?

Hi Sebastien, once a version is in proxy.golang.org, it usually can't be removed. This is important to ensure that builds continue working when a repository disappears upstream. You may want to publish a new version with a retract directive in go.mod, marking the earlier versions as invalid. In Go

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

The go command used to infer the module path from .git/config for github origins specifically. However, that was removed in 1.13, based on discussion in #27951 . It wasn't a strong enough signal, and since it's important to get the module path right early

Re: [go-nuts] Trying to use a tool in my build (a friction log)

> Is it by design that these two commands ['go mod tidy' and 'go mod vendor'] are unstable like that? That is more or less by design, but the behavior has evolved over time and it may be worth revisiting. This was discussed in #29058 . The rationale was

Re: [go-nuts] Trying to use a tool in my build (a friction log)

Hey Tim, thanks for writing this up. These kinds of reports are helpful. I'll try to respond to a few problems individually. *1. Command installation with "go install"* There are basically two ways to do this, depending on whether you want to install the command within the context of your current

Re: [go-nuts] `go list` across multiple modules?

You appear to have discovered another new bug. Sorry for that. I've opened #43806 to track it. With that bug, it doesn't look like `go list` with local paths (relative or absolute) in a repository with nested replacement directories will work (at least n

Re: [go-nuts] `go list` across multiple modules?

By the way, I'm not sure if you're already doing this, but if you can batch all of the `go list` runs (or go/packages.Load) together per module (passing an argument per package), that will be much faster than loading individual packages with separate `go list` calls. It will save `go list` from hav

Re: [go-nuts] `go list` across multiple modules?

> Interesting - is the difference the absolute paths vs relative? It looks like the bug has to do with whether the directory is below the main module root directory or not. If it is, the go command takes a path that assumes it's part of the main module, which it's not. > I hoped maybe `-modfile`

Re: [go-nuts] `go list` across multiple modules?

I was initially going to suggest adding the module subdirectories as requirements to the main go.mod, then replacing those with the subdirectories. module example.com/m go 1.15 require ( example.com/other1 v0.0.0 example.com/other2 v0.0.0 example.com/m/submod v0.0.0 ) replace ( example.

Re: [go-nuts] Re: Go 1.14 is released

Both pages were moved to the x/website repository so they could be kept up to date outside the 6-month release cycle. On Wed, Feb 26, 2020 at 7:33 AM HaWe wrote: > Firts of all, many thanks for a great new release. > >