Re: [go-nuts] go install of forked repo

`go install pkg@version` doesn't support installing from a fork. The argument is best understood as a module identity rather than source code location. - sean On Sat, Dec 3, 2022, 11:55 Duncan Harris wrote: > This seems a noddy question but can't easily find an answer with Google > apparently.

Re: [go-nuts] go install of forked repo

Check out go work I achieve it’s exactly what you are looking for, allowing for projects to use temporary local versions of packages On Sat, 3 Dec 2022 at 11:55, Duncan Harris wrote: > This seems a noddy question but can't easily find an answer with Google > apparently. I may have lost the plot

Re: [go-nuts] go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28 not working

GOMOD="/dev/null" either looks weird or there is something interesting new to learn here. On Sunday, July 24, 2022 at 2:22:49 AM UTC+2 James Brooke wrote: > Thanks again for following up on this Kurtis. The command is in the > subject line: "go install google.golang.org/protobuf/cmd/protoc...@

Re: [go-nuts] go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28 not working

Thanks again for following up on this Kurtis. The command is in the subject line: "go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28 not working". Apologies if that wasn't clear. I'm finding this confusing to say the least. Without any further changes to my system, and not heading t

Re: [go-nuts] go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28 not working

On Fri, Jul 22, 2022 at 6:03 PM James Brooke wrote: > - I simply tried to run that command in the terminal. I'm able to develop > go programs fine in GoLand, pulling in 3rd party dependencies etc. I just > can't seem to install this binary because of this GOROOT issue. > What command did you run

Re: [go-nuts] go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28 not working

Thank you for your reply Kurtis. In answer to your questions: - I simply tried to run that command in the terminal. I'm able to develop go programs fine in GoLand, pulling in 3rd party dependencies etc. I just can't seem to install this binary because of this GOROOT issue. - this is the output f

Re: [go-nuts] go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28 not working

On Fri, Jul 22, 2022 at 9:48 AM James Brooke wrote: > Hello, I'm struggling to work out why this isn't working. I'm getting the > following, any help greatly appreciated. It would help if you explained what you did that produced those error messages. You should probably also include the output

Re: [go-nuts] Go install

It looks like you are running into one of the various dubious Windows "security" features, this one seems related to "User Account Control". If you haven't solved this yet, try googling for the error that you are getting. For example, I searched "windows 10 user account control do you want to al

Re: [go-nuts] Go install

Insufficient information. You didn't tell us your OS. You didn't tell us how you installed the Go toolchain. You didn't tell us how you are invoking the Go command. Start by eliminating the "Visual Studio" IDE as a variable. What happens if you open a terminal CLI and simply type "go version"? On

Re: [go-nuts] go install, replace directive any ongoing discussions?

I'm actually making the argument that the error is in fact incorrect as the replace directive has always been about compilation and therefore they should always apply when installing a module's main package whether its remoting fetching the module via go install or when compiling a module directly.

Re: [go-nuts] go install, replace directive any ongoing discussions?

On Sun, 2021-03-07 at 07:57 +, Paul Jolly wrote: > Erroring on replace directives is an intentional decision for now: > https://github.com/golang/go/issues/40276#issue-659471259 > > But might be relaxed in the future: > > > Parts of this proposal are more strict than is technically > > necessar

Re: [go-nuts] go install, replace directive any ongoing discussions?

well an issue was filed, and promptly closed. On Sun, Mar 7, 2021 at 6:36 AM James Lawrence wrote: > I read through those issues Paul, I found them less than convincing for > the global go install use case. regardless I'll file an issue. I didn't > wan

Re: [go-nuts] go install, replace directive any ongoing discussions?

I read through those issues Paul, I found them less than convincing for the global go install use case. regardless I'll file an issue. I didn't want to file an issue because of how long and pointless most of the conversation around the global install replace directive usage seemed. I'll file other

Re: [go-nuts] go install, replace directive any ongoing discussions?

I wasn't aware that this restriction is intentional. I wasn't part of that discussion and it seems too long for me to read after the fact, so I probably shouldn't comment on it. I'm admittedly a bit befuddled by the design decisions, though (as I understand them). On Sun, Mar 7, 2021 at 8:57 AM Pa

Re: [go-nuts] go install, replace directive any ongoing discussions?

>> I missed the conversation originally. however go install has been left in a >> unfortunate state where it bewilderingly errors out when the main module >> contains a replace directive. > > This sounds like a bug. I would file an issue with an easy reproduction case. Erroring on replace direct

Re: [go-nuts] go install, replace directive any ongoing discussions?

On Sun, Mar 7, 2021 at 3:45 AM James Lawrence wrote: > I missed the conversation originally. however go install has been left in > a unfortunate state where it bewilderingly errors out when the main module > contains a replace directive. > This sounds like a bug. I would file an issue with an ea

Re: [go-nuts] go install puts my library .a file in the local directory instead of first component of GOPATH

On Sun, Sep 6, 2020 at 9:15 PM Dean Schulze wrote: > When I execute go install datepackage I get This is may or may not be the cause, but please note that import paths without a dot, like the one quoted above, are reserved (https://github.com/golang/go/issues/32819#issuecomment-566671328) for th

Re: [go-nuts] go install touches the result file even if no changes

If you want to see why people give me a hard time: https://github.com/kubernetes/kubernetes/blob/master/build/root/Makefile.generated_files And that's AFTER a massive simplification. On Mon, Jan 28, 2019 at 11:55 AM Ian Lance Taylor wrote: > > On Mon, Jan 28, 2019 at 11:44 AM Tim Hockin wrote:

Re: [go-nuts] go install touches the result file even if no changes

On Mon, Jan 28, 2019, at 19:44, 'Tim Hockin' via golang-nuts wrote: > People already chide me for my affinity for baroque > Makefiles... I use bmake too; and here I was all this time thinking that the "b" stood for "BSD". —Sam -- You received this message because you are subscribed to the Goog

Re: [go-nuts] go install touches the result file even if no changes

On Mon, Jan 28, 2019 at 11:44 AM Tim Hockin wrote: > > Of course you are right, as usual. I just felt like that was a lot of > hoop-jumping. People already chide me for my affinity for baroque > Makefiles... If you can assume that you are using GNU make, the Makefile language is Turing complete

Re: [go-nuts] go install touches the result file even if no changes

Of course you are right, as usual. I just felt like that was a lot of hoop-jumping. People already chide me for my affinity for baroque Makefiles... On Sat, Jan 26, 2019 at 11:01 AM Ian Lance Taylor wrote: > > On Fri, Jan 25, 2019 at 7:55 PM Tim Hockin wrote: > > > > Fair point, of course. > >

Re: [go-nuts] go install touches the result file even if no changes

On Fri, Jan 25, 2019 at 11:43 PM Paul Jolly wrote: > > Tim - in case it's of any interest, I am in the process of (re)writing > a dependency-aware wrapper around go generate that caches results in > an artefact cache (i.e. only re-runs code generation as required). Yes interested. Happy to talk

Re: [go-nuts] go install touches the result file even if no changes

On Fri, Jan 25, 2019 at 7:55 PM Tim Hockin wrote: > > Fair point, of course. > > I care because Kubernetes and it's family of projects have Makefiles to > encapsulate trickier aspects of building, including code generation. > Compiling kubernetes takes a LONG time. It would be nice to avoid >

Re: [go-nuts] go install touches the result file even if no changes

Tim - in case it's of any interest, I am in the process of (re)writing a dependency-aware wrapper around go generate that caches results in an artefact cache (i.e. only re-runs code generation as required). On Sat, 26 Jan 2019 at 03:56, 'Tim Hockin' via golang-nuts wrote: > > Fair point, of cours

Re: [go-nuts] go install touches the result file even if no changes

Fair point, of course. I care because Kubernetes and it's family of projects have Makefiles to encapsulate trickier aspects of building, including code generation. Compiling kubernetes takes a LONG time. It would be nice to avoid re-triggering secondary actions when the primary artifacts have not

Re: [go-nuts] go install touches the result file even if no changes

On Fri, Jan 25, 2019 at 3:51 PM Tim Hockin wrote: > > I don't grok that reasoning - can you expand on it? Assume for a > second that it did NOT update mtime if the result did not change. I > can be confident that same mtime == no change, right? It doesn't > imply that different mtime == somethi

Re: [go-nuts] go install touches the result file even if no changes

I don't grok that reasoning - can you expand on it? Assume for a second that it did NOT update mtime if the result did not change. I can be confident that same mtime == no change, right? It doesn't imply that different mtime == something change, but I think that's OK (for my use, maybe I am limi

Re: [go-nuts] go install touches the result file even if no changes

On Fri, Jan 25, 2019 at 1:07 PM 'Tim Hockin' via golang-nuts wrote: > > Example: > > ``` > $ which git-sync > > $ go install -installsuffix "static" ./cmd/git-sync/ > > $ ls -l --full-time `which git-sync`; md5sum `which git-sync` > -rwxr-xr-x 1 thockin primarygroup 13956902 2019-01-25 > 13:04:40.

Re: [go-nuts] Go Install

This was also raised in https://github.com/golang/go/issues/24506 and is being fixed in the linked CL On Tue, 7 Aug 2018 at 06:33, John More wrote: > > You are right, using the -i option did the deed. > Thanks > John > > On Tue, Aug 7, 2018 at 1:26 AM, Ian Lance Taylor wrote: >> >> On Mon, Aug 6,

Re: [go-nuts] Go Install

You are right, using the -i option did the deed. Thanks John On Tue, Aug 7, 2018 at 1:26 AM, Ian Lance Taylor wrote: > On Mon, Aug 6, 2018 at 7:09 PM, John More wrote: > > following the tutorial at https://golang.org/doc/code.html the go > install I > > am confused by the following statement: >

Re: [go-nuts] Go Install

On Mon, Aug 6, 2018 at 7:09 PM, John More wrote: > following the tutorial at https://golang.org/doc/code.html the go install I > am confused by the following statement: > > > Whenever the go tool installs a package or binary, it also installs whatever > dependencies it has. So when you install the

Re: [go-nuts] "go install": no warning/error when binaries conflict

Random drive-by comment... Another solution would be to have go install put its results in subdirectories beneath $GOPATH/bin corresponding to source packages. For example, considering the program goimports: $ go get golang.org/x/tools/cmd/goimports $ go list -f '{{.Target}}' golang.org/x/tools/

Re: [go-nuts] "go install": no warning/error when binaries conflict

On Tue, Jul 18, 2017 at 7:27 AM, wrote: > > Consider a package with multiple binaries with the same name, "cmd" in this > case: > > pkg1/cmd/main.go: > package main; import "fmt"; func main() { fmt.Println("pkg1") } > > pkg2/cmd/main.go: > package main; import "fmt"; func main() { fmt.Println("pk

Re: [go-nuts] Go install recreates .a files that are already present in the pkg directory

I am getting *build ID mismatch* and here I see that it means that something has changed in the package, but I have not modified it in any way. Below is the whole application : package main import ( "os" "github.com/gotk3/gotk3/gtk" ) f

Re: [go-nuts] Go install recreates .a files that are already present in the pkg directory

I am getting *build ID mismatch* and here I see that it means that something has changed in the package, but I have not modified it in any way. Below is the whole application : package main import ( "os" "github.com/gotk3/gotk3/gtk" ) f

Re: [go-nuts] Go install recreates .a files that are already present in the pkg directory

On Fri, Jul 14, 2017 at 6:27 AM, wrote: > Hey, > > I formatted my OS and now i am having a problem that was not present before. > I am trying to use gotk3 and when i try to install it i run > > go install -v -tags gtk_3_18 > > It used to only rebuild (correct me if im using a wrong verb here) the

Re: [go-nuts] go install seems to do a lot of rebuilding in a container

Yes, that was the problem. We were building with CGO_ENABLED=0, which was meaning that built-in packages like "os/user" were always stale and causing rebuilds of almost every other package. Putting this in my dockerfile (along with mounting the pkg directory as a volume shared between each bui

Re: [go-nuts] go install seems to do a lot of rebuilding in a container

Thanks, that's given me a great thread to pull on. All the rebuilds track back to os/user being stale due to build ID mismatch. Probably an issue with the specific configuration we've set up for our build being different to the pre-build os/user (I think we disable CGO, for one). Should be ab

Re: [go-nuts] go install seems to do a lot of rebuilding in a container

On Thu, Dec 8, 2016 at 10:13 AM, wrote: > I've started with a clean pkg dir. > > It's odd; the mtimes look correct (same inside/outside container). the > "buildid" to the compile commands s the same on each run too. > > Does anyone know if there's a way to print out the "StaleReason" that the >

Re: [go-nuts] go install seems to do a lot of rebuilding in a container

I've started with a clean pkg dir. It's odd; the mtimes look correct (same inside/outside container). the "buildid" to the compile commands s the same on each run too. Does anyone know if there's a way to print out the "StaleReason" that the code collects, that might help me find out what gate

Re: [go-nuts] go install seems to do a lot of rebuilding in a container

s/go build -i/go install. On Thu, Dec 8, 2016 at 8:07 AM, andrey mirtchovski wrote: > it's also possible that you need to do "go build -i" just in case your > dependencies are outdated. i had the same issue today with a windows > piece of code that rebuilt sqlite3 every time. > > > On Wed, Dec 7,

Re: [go-nuts] go install seems to do a lot of rebuilding in a container

it's also possible that you need to do "go build -i" just in case your dependencies are outdated. i had the same issue today with a windows piece of code that rebuilt sqlite3 every time. On Wed, Dec 7, 2016 at 2:57 PM, Dave Cheney wrote: > Docker add, or whatever is pushing files into your conta

Re: [go-nuts] go install with -installsuffix fails on linux but not mac?

(sorry if I already sent this - groups UI being weird) Hmm... I seem to get the same results on both machines: Mac: $ go list -f '{{.Name}} {{.Stale}}' std | grep true | head $ go list -installsuffix nocgo -f '{{.Name}} {{.Stale}}' std | grep true | head tar true zip true bzip2 true lzw true

Re: [go-nuts] go install with -installsuffix fails on linux but not mac?

On Mon, Oct 10, 2016 at 12:48 PM, Ian Rose wrote: > On my macbook pro, I'm able to `go install` with a custom installsuffix just > fine: > > > $ ls -l /usr/local/go/pkg/ > total 0 > drwxr-xr-x 5 root wheel 170 Feb 25 2016 bootstrap > drwxr-xr-x 58 root wheel 1972 Feb 25 2016 darwin_amd64