[go-nuts] Re: Modules... why it has to be so painfull?

2023-05-19 Thread Howard C. Shaw III
Workspaces make this all much easier for me. https://go.dev/doc/tutorial/workspaces go work I was going mad trying to get modules to work reasonably until I found that. Now, new directory, go mod init , go work use ., go work sync, go tidy, and everything works reasonably without major headache

Re: [go-nuts] Re: Modules... why it has to be so painfull?

2021-04-09 Thread Justin Israel
On Sat, Apr 10, 2021 at 3:38 AM 'gonutz' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Justin Isreael said > > "Changes to ProjectB should be immediately available when compiling > ProjectA." > > which is not true when you simply insert a replace in your go.mod file. > > My current prob

Re: [go-nuts] Re: Modules... why it has to be so painfull?

2021-04-09 Thread roger peppe
On Fri, 9 Apr 2021, 16:37 'gonutz' via golang-nuts, < golang-nuts@googlegroups.com> wrote: > Justin Isreael said > > "Changes to ProjectB should be immediately available when compiling > ProjectA." > > which is not true when you simply insert a replace in your go.mod file. > > My current problem i

[go-nuts] Re: Modules... why it has to be so painfull?

2021-04-09 Thread Volker Dobler
On Friday, 9 April 2021 at 17:38:12 UTC+2 gonutz wrote: > A replace in the go.mod file is of no help here because I still have to > specify a require with a concrete version or commit hash for the library. > Why do you think so? Replace with your local filesystem path of the library requires n

[go-nuts] Re: Modules... why it has to be so painfull?

2021-04-09 Thread oldCoderException
I certainly agree with everyone who has been saying that implementing modules can be painful. Implementing them was initially a multi-week nightmare of sleepless nights for me, and I still sometimes shake my head with their use. I think that a large part of the problem is that the documentati

[go-nuts] Re: Modules... why it has to be so painfull?

2021-04-09 Thread 'Carla Pfaff' via golang-nuts
On Friday, 9 April 2021 at 17:38:12 UTC+2 gonutz wrote: > A replace in the go.mod file is of no help here because I still have to > specify a require with a concrete version or commit hash for the library. > This means I cannot just change the code in the library module, I also have > to create

[go-nuts] Re: Modules... why it has to be so painfull?

2021-04-09 Thread 'gonutz' via golang-nuts
Justin Isreael said "Changes to ProjectB should be immediately available when compiling ProjectA." which is not true when you simply insert a replace in your go.mod file. My current problem is that I have a main module that uses a library module. I want to debug an issue so I insert a print st

[go-nuts] Re: Modules... why it has to be so painfull?

2021-04-08 Thread Robert Solomon
I agree w/ your basic premise, that modules are quite painful. However, after much trials, tribulations, and posting here, I received the solution that allows me to structure my code as before (and like you, all in ~/go/src). I only had to edit the import strings to reflect "src/mypackage" in