Re: [go-nuts] "go-import" is great, we need "go-delete"

2025-01-12 Thread Jeffery Carr
On Wed, Jan 8, 2025 at 6:51 PM Ian Lance Taylor wrote: Hello! https://go.dev/desidesign/25530-sumdbgn/25530-sumdb. > Ironically, someone did 'go-delete' on that package so the document is missing ;) Yes, a consequence of a secure module proxy is that module names can't > be reused. Fortunately

Re: [go-nuts] "go-import" is great, we need "go-delete"

2025-01-08 Thread Jeffery Carr
On Tuesday, January 7, 2025 at 8:25:46 PM UTC-6 will@gmail.com wrote: If the package has been downloaded by the Go proxy but not a go tool, then request that the package be removed from the proxy. This is a landmark. I have to use system o

Re: [go-nuts] "go-import" is great, we need "go-delete"

2025-01-08 Thread Jeffery Carr
On Sat, Jan 4, 2025 at 10:54 AM Christoph Berger < christophberger@gmail.com> wrote: > > We need "go-delete". Security is not important to us. There should be a > balance between people that need security and people that don't need it. > > Security might not be important to you, but it is impo

Re: [go-nuts] "go-import" is great, we need "go-delete"

2024-12-27 Thread Jeffery Carr
On Friday, December 27, 2024 at 7:17:41 PM UTC-6 Dan Kortschak wrote: On Fri, 2024-12-27 at 17:01 -0800, Jeffery Carr wrote: > I won't go into the nefarious reasons here. Let's just say it's going > to have to be fixed. > > Cryptographically signing this is bad.

Re: [go-nuts] "go-import" is great, we need "go-delete"

2024-12-27 Thread Jeffery Carr
On Friday, December 27, 2024 at 6:58:18 PM UTC-6 Sean Liao wrote: It does not exist, and is not possible due to the guarantees the module ecosystem wishes to provide. Any removal request you file only hides the generated documentation. Well, I'm sure it exists. There are a million reasons, all

Re: [go-nuts] "go-import" is great, we need "go-delete"

2024-12-27 Thread Jeffery Carr
On Friday, December 27, 2024 at 6:56:00 PM UTC-6 Jeffery Carr wrote: On Friday, December 27, 2024 at 6:41:08 PM UTC-6 Sean Liao wrote: The public module ecosystem is backed by a transparency log https://go.dev/ref/mod#checksum-database This doesn't allow you to reuse (change the definiti

Re: [go-nuts] "go-import" is great, we need "go-delete"

2024-12-27 Thread Jeffery Carr
On Friday, December 27, 2024 at 6:41:08 PM UTC-6 Sean Liao wrote: The public module ecosystem is backed by a transparency log https://go.dev/ref/mod#checksum-database This doesn't allow you to reuse (change the definition of) any published module + tag combination observed by the proxy infrast

Re: [go-nuts] "go-import" is great, we need "go-delete"

2024-12-27 Thread Jeffery Carr
On Friday, December 27, 2024 at 6:08:51 PM UTC-6 Dan Kortschak wrote: On Fri, 2024-12-27 at 15:42 -0800, Jeffery Carr wrote: > The fact of the matter is that sometimes, I make really dumb > mistakes. In the case of versioning things wrong, or making namespace > errors, one needs to

[go-nuts] "go-import" is great, we need "go-delete"

2024-12-27 Thread Jeffery Carr
The fact of the matter is that sometimes, I make really dumb mistakes. In the case of versioning things wrong, or making namespace errors, one needs to redo the namespace from scratch. This means we need some sort of way of purging namespace paths. As far as I can tell, there is no way to do th

Re: [go-nuts] Re: Working with release candidates

2024-12-22 Thread Jeffery Carr
On Friday, December 20, 2024 at 5:49:04 PM UTC-6 Dan Kortschak wrote: Almost certainly not. The point of module version specification is to allow reproducible builds. Leaving this up to things outside the build's dependencies makes this non-achievable. Well, we agree then, but is this "tool

Re: [go-nuts] Re: Working with release candidates

2024-12-20 Thread Jeffery Carr
e, best left to the OS distribution and packaging people. jcarr On Fri, Dec 20, 2024 at 4:06 PM Jeffery Carr wrote: > Wow. This syntax is amazing! This would be really helpful. However, that > is not what I was talking about. I see > > go 1.22 > > toolchain go1.23.4 > > T

Re: [go-nuts] Re: Working with release candidates

2024-12-20 Thread Jeffery Carr
Wow. This syntax is amazing! This would be really helpful. However, that is not what I was talking about. I see go 1.22 toolchain go1.23.4 The above syntax is much worse than what you posted below. In either case, can you please put this in a new file "go.tool" perhaps? That would be fantastic

Re: [go-nuts] Re: Working with release candidates

2024-12-20 Thread Jeffery Carr
7;Brian Candler' via golang-nuts < golang-nuts@googlegroups.com> wrote: > > Can someone explain how to disable this? I never want to download > anything at compile time. > > go env -w GOTOOLCHAIN=local > > On Friday, 20 December 2024 at 15:07:43 UTC Jeffery Carr

[go-nuts] Re: Working with release candidates

2024-12-20 Thread Jeffery Carr
I also have noticed this new 'toolchain' option. I'm a bit confused about how it works. "This automatic toolchain switching can be disabled, but in that case, for more precise forwards compatibility, the go command will refuse to run in a main module or workspace in which the go line requires a

[go-nuts] On 'go install' for plugins

2024-12-19 Thread Jeffery Carr
For those of us that think go plugins are the most important piece of technology to come out since the sandwich toaster, being unable to 'go install' a plugin is a problem one wants to solve. Armed only with ignorance, I attacked this problem head on. Plunging directly into src/cmd/go/internal/

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-23 Thread Jeffery Carr
On Tuesday, March 5, 2024 at 9:29:58 AM UTC-6 Bryan C. Mills wrote: The simplest way to download Go dependencies for code review and debugging is to run `go mod vendor` in your module or (newly added) `go work vendor` in your workspace. Also note that `go mod download -json` and `go list -m -

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-13 Thread Jeffery Carr
On Thu, Mar 7, 2024 at 4:28 AM Jan Mercl <0xj...@gmail.com> wrote: > jnml@e5-1650:~/tmp/get$ GOPATH=$(pwd) GO111MODULE=auto go get -v > modernc.org/sqlite > > jnml@e5-1650:~/tmp/get$ ls pkg/mod/ > cache github.com golang.org modernc.org > Interesting, it does indeed pull the pkg/mod, but in

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-13 Thread Jeffery Carr
On Mon, Mar 11, 2024 at 10:05 AM roger peppe wrote: > It's not quite what you're after, but FWIW the gohack command ( > github.com/rogpeppe/gohack) knows enough to download arbitrary Go modules > including the VCS checkout. You might find it useful, I guess. > Okay, yes, I'm only 5 years late to

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-06 Thread Jeffery Carr
On Sunday, March 3, 2024 at 5:46:13 PM UTC-6 Christian Stewart wrote: Firstly, you can reference the other repos and use the latest "master" version by writing "master" where the v verson is in the file, then use "go mod tidy" Second, you can use "go work" to create a workspace with multip

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-06 Thread Jeffery Carr
On Tuesday, March 5, 2024 at 9:29:58 AM UTC-6 Bryan C. Mills wrote: Part of the intent with modules is that you do not need to do a full `git clone` of each dependency — you should really only need to do that if you need to author upstream changes yourself, Yes, I'm authoring upstream changes

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-04 Thread Jeffery Carr
On Monday, March 4, 2024 at 8:44:14 AM UTC-6 Bryan C. Mills wrote: Per https://go.dev/doc/go1.22#go-command: > go get is no longer supported outside of a module in the legacy GOPATH mode (that is, with GO111MODULE=off). Other build commands, such as go build and go test, will continue to work in

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-03 Thread Jeffery Carr
Yes, I do understand the go-source/go-import part, but am I missing something? I don't understand how you would find the go-source other than parsing the HTML I mean 'go get' used to do that for me, do I now have to write a program to do that? I don't understand why that is some bad idea. Yes

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-03 Thread Jeffery Carr
"You can build large projects with many repos using Go modules. " Also, I forgot to add, lots of my repos are binaries, so module things don't apply. How do I tell someone to download go.wit.com/apps/helloworld? I can't now with a single GO111MODULE=off go get. Can we have 'go download' or can

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-03 Thread Jeffery Carr
I don't think I understand you. How can I download go.uber.org/zap sources? I need to be able to do it using the "go" binary. I was able to do it before, now I can't. Is there some way to do go download go.uber.org/zap and have it git clone? I don't know how to resolve the git clone path. --

Re: [go-nuts] GO111MODULE=off go get deprecated?

2024-03-03 Thread Jeffery Carr
I guess this boils down to: GO111MODULE=off go get go.uber.org/zap used to git clone into ~/go/src/go.uber.org/zap How am I supposed to do that now? I assume I'm not expected to parse the HTML for the go-import and go-source lines! jcarr -- You received this message because you are subscribe

[go-nuts] GO111MODULE=off go get deprecated?

2024-03-03 Thread Jeffery Carr
Has this been deprecated or maybe it is broken in debian sid, but: bash$ GO111MODULE=off go get -v go.wit.com/apps/test go: modules disabled by GO111MODULE=off; see 'go help modules' basj$ go version go version go1.22.0 linux/amd64 this doesn't work anymore. Also, 'go help modules' is less than