Re: [go-nuts] Re: Web access to golang-dev is down

Hi Ian, I can now access golang-dev again via the web interface, whereas previously I could not. (Hopefully that is not a coincidence). Thanks for looking into this. Regards, thepudds On Tuesday, May 7, 2019 at 1:39:50 PM UTC-4, Ian Lance Taylor wrote: > > On Tue, May 7, 2019 at 8:01 AM

[go-nuts] Re: Working outside of VCS - parent/child modules

You do have the option to nest one module within another module in the same repo, but from what I have seen, that is usually not what one wants to do, and especially not to start. It can be tricky to set up correctly, and usually is more work on an on-going basis. The clearest statement I've

Re: [go-nuts] Re: Packaging a Go module for Nix

Hi Wael, Sorry, I am not quite following what you have and have not tried yet, and which issues you have hit with which techniques. Is one of the issues that the 'vcs' cache directory changes, even if the actual code you need for your build has not changed? If so, I wonder if you might be

Re: [go-nuts] Allow go mod download to store in subdirectory of current working directory

Jorrit, The simplest solution might be 'go mod vendor' to populate a 'vendor' directory, and then set '-mod=vendor' or 'GOFLAGS=-mod=vendor' when building. If that is not workable for some reason, here is an alternative that is more similar to your request for a 'go mod download -dir

[go-nuts] Re: How do I update all direct and indirect dependencies in go.mod

Hi Francis, To ask that your direct dependencies be upgraded to their latest available versions, you can do the following in Go 1.11 or 1.12: go get $(go list -f '{{if not (or .Main .Indirect)}}{{.Path}}{{end}}' -m all) Your indirect dependencies will be updated as needed according to the

Re: [go-nuts] why go get does not work outside a module?

The good news is that this is addressed for 1.12: #24250 cmd/go: allow "go get" when outside a module in module mode https://github.com/golang/go/issues/24250 It would be worthwhile to try the 1.12 release candidate if you can:

Re: [go-nuts] Re: Why is "v" prefix for VCS tag required for ?

To give a quick concrete example for the point below about still being able to make use of an existing tag that does not have a leading "v"... If you do the following from within a module (note no "v" in "0.0.3"): $ go get github.com/jondot/groundcontrol@0.0.3 The result is recorded in the

Re: [go-nuts] Re: Why is "v" prefix for VCS tag required for ?

As far as I understand it, there is a distinction drawn between: 1. a "semantic version" (where a leading "v" is not part of a "semantic version"), vs. 2. the mechanism for encoding a "semantic version" into a VCS tag (where a leading "v" is allowed) In other words, under that

[go-nuts] Re: performance of go mod verify

Hi Joe, Sorry, I realized I pasted in the wrong quote from the documentation. I meant to include this quote instead (from https://golang.org/cmd/go/#hdr-Module_downloading_and_verification): "The go command maintains, in the main module's root directory alongside go.mod, a file named go.sum

[go-nuts] Re: performance of go mod verify

Hi Joe, As far as I know, I think it is computing the SHA256 of the dependencies: https://github.com/golang/go/blob/release-branch.go1.11/src/cmd/go/internal/dirhash/hash.go#L25 Personally, I wouldn't expect that to get pathologically worse with more dependencies. Also, just as you can often

Re: [go-nuts] Go Modules And Sub-Packages

Assuming your repository is “github.com/user/package1”, your module is already on v3.1.9, you have a single go.mod file, and the go.mod file is in the root of the repository, then that would mean the first line in your go.mod file typically would be: module github.com/user/package1/v3 To

[go-nuts] Re: ...cannot find module for path...

Hi, You might be seeing an issue due to using an absolute path as your module path when you did 'go mod init /Users/me/goO/mycat'. Usually the module path should start with a hostname, including a dot (and I think that is a requirement if you with to publish the module and have it work with

[go-nuts] Re: pkg folder

Hi Alex, I think this quote from the documentation is intended to explain what you are seeing: "In module-aware mode, GOPATH no longer defines the meaning of imports during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod) and installed commands (in GOPATH/bin,

[go-nuts] modules: incrementing major version when adopting modules with v2+ packages

A brief PSA: If you are adopting modules with an existing v2+ package, the recommended best practice for most cases is to increment the major version when first adopting modules. For example, if you are on already on v2.2.0, then you would use v3.0.0 for your first release with modules.

[go-nuts] Re: go modules go build fails - normal go build with $GOPATH set works

Hi Robert, Just to echo what Sam said, there is a healthy chance this could be explained by a version mismatch, although maybe it could be something else. When you enable modules, by default it will look for the latest valid semver tag (https://semver.org) to satisfy any dependencies. For

Re: [go-nuts] Go offline development recommendations

Hi Sandro, Vendoring is another approach that can work here. In a pre-modules world, vendoring is fairly well known. In a modules world, vendoring is still an option. For example, you can see this FAQ here that touches on using 'go mod vendor' with modules:

[go-nuts] Re: Go += Package Versioning

Hi Göcs, Could you expand on your question, including a bit more about the scenario you are in, what you are seeing currently, and what you would like to see instead? It would probably help to include a simplified example that is representative of your question or issue. For example (and

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

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

[go-nuts] Re: Modules upgrade none transitive modules (aka direct modules)

Hi Jerome, Are you asking how to just upgrade your direct dependencies (and then your indirect dependencies are upgraded according to the various 'require' statements in the various 'go.mod' files)? If so, could you say a bit more about why you are interested in doing that? Also, you might be

[go-nuts] Re: handling unexpected module path

Joe, There's a good chance your diagnosis is correct -- my understanding is the path used in an import statement is required to match up with the module path in the 'module' directive in the imported module's go.mod file. In general, I think some projects have switched back and forth between

[go-nuts] Re: go src organization question

Hi Sankar, How many repos are you directly modifying? Most projects are likely following the simplest approach of using a single module per repository, which typically would mean creating one go.mod file located in the root directory of each repository. (The official modules proposal predicts

Re: [go-nuts] Go modules and replace

Hi all, See some related discussion here regarding dots in import paths and modules: https://github.com/golang/go/issues/27503 including this comment from bcmills: "Dotless paths in general are reserved for the standard library; go get has (to my knowledge) never worked with them, but go

[go-nuts] Re: Golang Modules/vgo - local changes push, merge and tags

Hi Guy, Right now, my understanding is there is not a perfect answer to your questions. However, these are very important questions, including I think community discussion right now can help establish alternative immediate solutions, as well as help shape how things might work in 1.12 and

Re: [go-nuts] `go mod download -json` does not product valid json?

Hi kalekold, It looks like it is a stream of JSON objects? If so, I suspect this is expected? See related discussion here (for 'go list -m -u -json' in this case), along with sample code for parsing: https://github.com/golang/go/issues/27655 --thepudds On Saturday, October 6, 2018 at

Re: [go-nuts] go mod: how to develop in multiple repos?

> "Is there an issue for this; it continues to fill me with dread that temporary edits to committed files are intended to be part of a development workflow." Hi kortschak, There is some related discussion here, which also includes some pointers to some related issues:

Re: [go-nuts] go mod tidy pulls in too much

Hi Scott, Regarding your comment, a related issue (which is still open) is this one: #26955: “cmd/go: provide straightforward way to see non-test dependencies” https://github.com/golang/go/issues/26955 —thepudds -- You received this message because you are subscribed to the Google

Re: [go-nuts] go mod tidy pulls in too much

Hi Harmen, And my first sentence might not have been clear. When I said "even in your current situation, 'go build' is still pulling in exactly what it needs", I was trying to reference the actual compilation process. In other words, I was just trying to make it clear that even if you have

Re: [go-nuts] go mod tidy pulls in too much

> "So if consul adds a go.mod file in the root, then `mod tidy` will suddenly behave as I would expect (i.e. not pull in unused dependencies)? " Hi Harmen, Just in case this isn't already clear-- note that even in your current situation, 'go build' is still pulling in exactly what it needs

[go-nuts] Re: Help tracking down module dependencies

Hi Justin, I'm not sure where that gotest.tools is coming from in your particular build, and not sure of the root cause of the issue with your http proxy. However, one thing you could try is a 'replace' directive to try to get gotest.tools directly from github. I don't know if that will help

Re: [go-nuts] Re: Using modules with go test ./...

Hi Scott, all, > "also I think they have obligated themselves to maintaining support for the current functionality, which some might not find fitting to the way they work." Regarding the concern raised in that post -- I think it is definitely not too late to give feedback on how modules

Re: [go-nuts] Re: Using modules with go test ./...

> "I imagine I might be in the minority in using test this way. Its useful when you have a small monorepo to do tests. People who run large monorepos must have advanced tooling and individual modules won't notice the behavior change." Hi John, Stepping back, one side question: how

Re: [go-nuts] Re: Using modules with go test ./...

> "What I would expect with 'go test ./...' is behavior similar to what I had before modules." Hi John, all, Just to expand slightly on the points from Dave, Scott, and Paul... I suspect part of what you are encountering is that in general: 1. Modules are opt-in for Go 1.11, so by

Re: [go-nuts] modules and package cyclic dips

Hi Scott, Great, it looks like you ran your own test too. (We had both posted at approximately the same time a few minutes ago). --thepudds On Sunday, September 16, 2018 at 4:05:16 PM UTC-4, thepud...@gmail.com wrote: > > Hi Scott, > > Regarding your question about pre-release tags and 'go

Re: [go-nuts] modules and package cyclic dips

Hi Scott, Regarding your question about pre-release tags and 'go get -u', my understanding is that when the documentation says: 'The -u flag instructs get to update dependencies to use newer minor or patch releases when available.' ...the use of the phrase 'newer minor or patch release'

Re: [go-nuts] modules and package cyclic dips

Hi Scott, Modules do provide support for semver pre-release notation. You can read more about it in these sections of the documentation, for example: https://tip.golang.org/cmd/go/#hdr-Module_queries https://tip.golang.org/cmd/go/#hdr-Pseudo_versions

Re: [go-nuts] modules and package cyclic dips

Hi all, One additional set of brief comments. This was a fairly nuanced and long thread, and I'm pretty sure I did not follow all of it, but I think a question related to the conversation here is -- what does 'require foo v1.1.1' really mean? Perhaps one way to think about that usage of the

Re: [go-nuts] modules and package cyclic dips

> "Maybe having a way for "go mod" to output what is used would be less confusing?" Hi all, To see a list of the selected module versions, one way is to use use 'go list -m all'. This shows the actual versions used based on all of the various requirements in a build. Sample output: $

Re: [go-nuts] variables name and scope

Some people strongly recommend always including `-shadow` when running `go vet`. Using your example: $ go vet -shadow # example .\main.go:20: declaration of "p" shadows declaration at .\main.go:15 --thepudds On Thursday, September 13, 2018 at 9:54:05 AM UTC-4, Jan Mercl wrote: > > On

Re: [go-nuts] Re: How to setup your development environment using Go modules

Hi all, Also, for reference, here are three other related issues: #26640 "cmd/go: allow go.mod.local to contain replace/exclude lines" https://github.com/golang/go/issues/26640 #26377 "proposal: cmd/go: module semantics in $GOPATH/src" https://github.com/golang/go/issues/26377

Re: [go-nuts] Re: How to setup your development environment using Go modules

Seth and/or Mirko, What would you think about one of you opening a new issue that covers the possible approach you were outlining earlier in this thread: "Another idea is to have a sort of "publish local" semantics, where the go tool has support for something like -devel tags, which

Re: [go-nuts] Re: How to setup your development environment using Go modules

Hi all, This thread is hitting on a fairly important set of topics. It certainly seems some additional brainstorming and community discussion about how things could or should work regarding multi-module workspaces would be beneficial. A file tree with a `go.mod` has been described as

[go-nuts] Re: Fail build on missing dependencies

Hi, A few quick comments. There is a there is fair amount of flexibility to adjust the default behavior for the go tooling in terms of when it updates `go.mod`, when it is allowed to reach out to the network, when it uses the vendor directory, etc. In your case, you could consider something

[go-nuts] Re: `exec: "gcc": executable file not found in $PATH` when compiling as a module

Hi all, In a separate (short) forum, Russ wrote: "Because the pre-built packages are non-module builds and can’t be reused. Sorry. Disable cgo for now or install gcc." I suspect these are related as well: #26993 -- "cmd/go: prebuilt net/http not used"

[go-nuts] Re: Local repository for go modules

"There is no VCS, only a tree in my own file system." Hi Ignazio, I think you could go down the Athens path if you wanted to, but I don't think you need to do so. I suspect the 'replace' directive I described in my earlier post in this thread might be sufficient for what you describe,

[go-nuts] Re: Local repository for go modules

Hi Ignazio, Athens is one option, but there are also possible options depending on what you are trying to accomplish. Could you say a few more words about your use case? If you are doing something simple, like experimenting with creating a hello world module in something like /tmp/hello, then

[go-nuts] modules: significant changes since the first vgo blog series?

Hi all, It's been a bit tricky to track how vgo/Go 1.11 modules have evolved since the first vgo blog series and since the official proposal was published. To help with that, I tried to put together a list of some of the larger user-facing changes in approach that happened after the first vgo

Re: [go-nuts] implementation of sync.atomic primitives

Hi Ian, I know you were not giving any type of definitive treatise on how go treats atomics across different processors... but is a related aspect restricting instruction reordering by the compiler itself? I don't know what the modern go compiler does at this point, but I think at least

Re: [go-nuts] implementation of sync.atomic primitives

Hi Shivaram, Regarding the memory model definition and sync/atomic, there is this github issue that you likely would be interested in: issue #5045 "doc: define how sync/atomic interacts with memory model" Including this comment: =

[go-nuts] Re: How to reuse go fix tool code

Hi Anuj, Two quick comments. 1. FYI, in case you didn't see this in the recent vgo dependency management discussion, go fix might start to be used much more broadly in the not-too-distant future across the go community as a way to help automate in some cases the ability to update client code

[go-nuts] Re: Long running task in select case

Hi all, In this particular case, this is a toy example of course, but for this toy example, it is absolutely a case where the performance of the synchronization primitive literally does not matter at all. (If I followed here, the intent is seemingly to watch a long running task, and the

[go-nuts] Re: Long running task in select case

> > *> "Here's another way: https://play.golang.org/p/gEDef3LolAZ > "* Hi all, I think the second example alternative given (playground link above) has a data race? Sample race detector run just now. (The two reports are inverses of each other: read

Re: [go-nuts] Channels vs Callbacks in API

On a semi-related note, I think there is a fair amount of wisdom in the "Synchronous Functions" section of the Code Review Comments golang wiki page (including it is not written as an absolute and starts with the word "Prefer").