go mod dependency hell is real

[Darko Luketic]

What used to work pre go 1.13 now doesn't work anymore

go mod is one big mess no one needs and complicates everything

I'm now getting ambiguity. How do I resolve it?

Nothing compiles anymore

 ✘ darko@wrk  ~/go/src/git.icod.de/dalu/socialthing   master ●✚  go mod tidy

go: extracting github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8

git.icod.de/dalu/socialthing/cmd imports

        github.com/gin-gonic/gin/binding imports

        github.com/ugorji/go/codec: ambiguous import: found github.com/ugorji/go/codec in multiple modules:

        github.com/ugorji/go v1.1.4 (/home/darko/go/pkg/mod/github.com/ugorji/g...@v1.1.4/codec)

        github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8 (/home/darko/go/pkg/mod/github.com/ugorji/go/co...@v0.0.0-20181204163529-d75b2dcb6bc8)

What does that even mean?

Why?

How do I fix this?

How do I permanently disable go mod?

I don't want it, I don't need it.

build git.icod.de/dalu/socialthing: cannot load github.com/ugorji/go/codec: ambiguous import: found github.com/ugorji/go/codec in multiple modules:

github.com/ugorji/go v1.1.4 (/home/darko/go/pkg/mod/github.com/ugorji/g...@v1.1.4/codec)

github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8 (/home/darko/go/pkg/mod/github.com/ugorji/go/co...@v0.0.0-20181204163529-d75b2dcb6bc8)

/wrist

[Darko Luketic]

The answer is apparently

https://github.com/gin-gonic/gin/issues/2039#issuecomment-527997733

Add this to your go.mod file:
replace github.com/ugorji/go v1.1.4 => github.com/ugorji/go v0.0.0-20190204201341-e444a5086c43

[Sam Whited]

Note that replace directives are not transitive, so every single user of
your library will need to do this. You can put it into your go.mod file
to get your library building and get tests passing, but your users will
still have to do this work as well so you'll probably want to document
that they now have to jump through hoops to use your library.

—Sam

On Tue, Sep 10, 2019, at 13:10, Darko Luketic wrote:
> The answer is apparently
> https://github.com/gin-gonic/gin/issues/2039#issuecomment-527997733
>
> > Add this to your go.mod file: `replace github.com/ugorji/go v1.1.4
> > => github.com/ugorji/go v0.0.0-20190204201341-e444a5086c43`
> On Tuesday, September 10, 2019 at 2:48:25 PM UTC+2, Darko
> Luketic wrote:
> > What used to work pre go 1.13 now doesn't work anymore

--
Sam Whited

[t hepudds]

Hello Darko,

Rather than that 'replace' you found, a better solution is probably adding a 'require' for a more recent release of github.com/ugorji/go.

Adding this to my go.mod worked for me in a simple test just now to resolve a similar error to what you reported:

  require github.com/ugorji/go v1.1.7 

Using a 'require' for a recent version is better than the 'replace' you found for a couple reasons, including it is more forward looking, it ages out more gracefully, it helps anyone importing your project (avoiding the problem Sam W. just commented on), etc.

Or, you likely could use a later version than v1.1.7.

The v1.1.7 release of github.com/ugorji/go was specifically targeting resolving the error you reported, I believe. Some more details here if interested:

   https://github.com/ugorji/go/issues/299

Regards,

thepudds

[Darko Luketic]

Hey Sam and Pudds,

thanks for feedback and help. v1.1.7 helped.

I must say go.mod is growing on me, but it's still hindering productivity or let's say a step back.

If you use Goland, which probably most mousepushers like me use, since everything is under ~/go/pkg/

even with modules enabled in the IDE, if you don't know the exact type, it won't autocomplete anymore

And for each subdirectory that is not yet "connected" to the main package or root level updating imports and go.mod/sum needs to be done seperately

or else you won't have code completion.

So this involves finding the package name, going to their repository then finding the godoc reference, clicking on it, and searching on the page for the correct type.

For instance I forgot

r := gin.Default()

was it gin.New() or was it gin.NewRouter() ? I forgot.

So I had to do the whole jazz wasting time.

Previous to go modules, it's in ~/go/src/ the IDE had indexed the paths and it's available.

Now you can say, "that's not a Go modules problem, that's the IDE". Well yeah but the factual reality is, it's a step backwards in productivity.

Maybe it really is an IDE issue and it doesn't happen in vim.

Another concern is this Google proxy by default. That is really something I find feels like betrayal.

I didn't know every go modules request goes through a Google proxy by default until I read more about the modules topic.

And the resolution of this problem wasn't very obvious, but I had to read through obscure documentation.

Read the privacy policy if you can find it, then read the rather long document (longer than a simple: here's the one-line that turns off this builtin spyware)

All leaving a sour taste.

I wonder what kind of spyware Go v2 will include by default.

Not happy.

[ant...@aporeto.com]

Hi, 

but require 1.2.0 will not work if another dependency requires the same package at version 1.1.0 thanks to mvs.

So either I'm wrong and I did not understand mvs, in that case I would like to get enlighten, or I got that right and that comforts me in my deep hate of mvs.

[Jakob Borg]

On 14 Sep 2019, at 01:52, ant...@aporeto.com wrote:

but require 1.2.0 will not work if another dependency requires the same package at version 1.1.0 thanks to mvs.

So either I'm wrong and I did not understand mvs, in that case I would like to get enlighten, or I got that right and that comforts me in my deep hate of mvs.

Luckily, you're wrong on this point. MVS means that if you require 1.2.0 and some dependency requires 1.1.0, you'll both get 1.2.0. (And not, say, 1.3.49).

//jb

[Antoine Mercadal]

Hey,

Then why is it called mvs? I don't understand what package system would give me 1.3.49, if I require 1.2.0 and my dependency requires 1.1.0.

I'll read a bit more about it, but you may have decreased my level of go module hate by a bit, sir :)

Thanks,

-- 

Antoine Mercadal

[Chris Broadfoot]

Is this the issue you came across the other day, Jean?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/BF3BD86E-47E7-4D85-A25E-EFA2E42C020E%40aporeto.com.

[Jakob Borg]

On 14 Sep 2019, at 08:32, Antoine Mercadal <ant...@aporeto.com> wrote:
>
> Hey,
>
> Then why is it called mvs? I don't understand what package system would give me 1.3.49, if I require 1.2.0 and my dependency requires 1.1.0.
>
> I'll read a bit more about it, but you may have decreased my level of go module hate by a bit, sir :)

Lacking other constraints, or with the general "major version 1" constraint that covers your example, many other package managers would default to the latest compatible version at installation time (i.e., 1.3.49). MVS picks the oldest compatible version, 1.2.0.

//jb

[roger peppe]

On Sat, 14 Sep 2019, 07:32 Antoine Mercadal, <ant...@aporeto.com> wrote:

Hey,

Then why is it called mvs? I don't understand what package system would give me 1.3.49, if I require 1.2.0 and my dependency requires 1.1.0.

Any time you don't understand why the versions have resolved in a particular way, I'd recommend looking at the output of `go mod graph`, which shows all the information used by the MVS algorithm (piping it through grep to see only the module you're interested in works well).

I've found it invaluable on many occasions.

I'll read a bit more about it, but you may have decreased my level of go module hate by a bit, sir :)

Thanks,

-- 

Antoine Mercadal

On Sep 13, 2019, at 11:05 PM, Jakob Borg <ja...@kastelo.net> wrote:

On 14 Sep 2019, at 01:52, ant...@aporeto.com wrote:

but require 1.2.0 will not work if another dependency requires the same package at version 1.1.0 thanks to mvs.

So either I'm wrong and I did not understand mvs, in that case I would like to get enlighten, or I got that right and that comforts me in my deep hate of mvs.

Luckily, you're wrong on this point. MVS means that if you require 1.2.0 and some dependency requires 1.1.0, you'll both get 1.2.0. (And not, say, 1.3.49).

//jb

--

[Manlio Perillo]

On Tuesday, September 10, 2019 at 2:48:25 PM UTC+2, Darko Luketic wrote:

What used to work pre go 1.13 now doesn't work anymore

go mod is one big mess no one needs and complicates everything

I'm now getting ambiguity. How do I resolve it?

Nothing compiles anymore

 ✘ darko@wrk  ~/go/src/git.icod.de/dalu/socialthing   master ●✚  go mod tidy

go: extracting github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8

git.icod.de/dalu/socialthing/cmd imports

        github.com/gin-gonic/gin/binding imports

        github.com/ugorji/go/codec: ambiguous import: found github.com/ugorji/go/codec in multiple modules:

        github.com/ugorji/go v1.1.4 (/home/darko/go/pkg/mod/github.com/ugorji/g...@v1.1.4/codec)

        github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8 (/home/darko/go/pkg/mod/github.com/ugorji/go/co...@v0.0.0-20181204163529-d75b2dcb6bc8)

What does that even mean?

I agree that the error message is too short.

I hope that in a future version, the go compiler will add a long description to each error message.

> [...]

Manlio Perillo

[ariebr...@gmail.com]

Update ugorji to v1.7 works for me