darccio/mergo

Vanity name makes live hard for developers

andig opened this issue · 9 comments

andig commented

Consider this (after replacing all import clauses):

go get -u
go: github.com/imdario/mergo@v1.0.0: parsing go.mod:
	module declares its path as: dario.cat/mergo
	        but was required as: github.com/imdario/mergo
	restoring github.com/imdario/mergo@v0.3.16

I assume this comes from a dependency but it seems as if I will always see this error now until all dependencies have upgraded?

Worse still: if I don't want to go through this pain and decide to stay with the old name, I'll still get the above errors since Go will try upgrade from prerelease to 1.0.

Also, opening dario.cat/mergo in browser (which I always do when troubleshooting) returns empty page.

darccio commented

@andig I can't revert the vanity URL without causing major issues. The change was announced one month before through an empty release, and the community has updated with no major issues.

Also, it seems that there may be some hidden issue in the Go tooling, because go install and go build work in different ways around versions: #240 (comment)

Respecting to your case, I will need to see your go.mod file to see which dependency may be importing mergo too.

In the meanwhile, it's possible that you will have to see this warning. Sorry for the inconvenience.

I'll look the empty page issue, as it should redirect to the repository.

andig commented

I can't revert the vanity URL without causing major issues.

Yeah, understand. I didn't want to imply this was done wrong or with bad intentions- just explain what happened to me at least.

Respecting to your case, I will need to see your go.mod file to see which dependency may be importing mergo too.

It's https://github.com/evcc-io/evcc/blob/master/go.mod but you surely can't take care for all the consumers!

In the meanwhile, it's possible that you will have to see this warning. Sorry for the inconvenience.

Yeah, realize that. I think for time being I'm fine as long as I stay on the old name (though bugfixing will cease for be). Imho the lesson learned here is that- given how go get works- it would be best practice to have name changes only with major versions that are expected to contain breaking changes (behind a v2 tag).
While prereleases are also expected to break, doing so after years of development when switching to v1 breaks everyone still (indirectly) consuming prereleases as those will suffer during the forced upgrade to v1. Lesson learned :)

Thank you!

darccio commented

@andig From what I see, sprig is also importing my library:

dario@LAPTOP-Q38PUD8E:~/code/evcc$ go mod graph | grep mergo
github.com/evcc-io/evcc github.com/imdario/mergo@v0.3.16
github.com/Masterminds/sprig/v3@v3.2.3 github.com/imdario/mergo@v0.3.11
github.com/imdario/mergo@v0.3.16 gopkg.in/yaml.v3@v3.0.1
github.com/imdario/mergo@v0.3.11 gopkg.in/yaml.v2@v2.3.0

My suggestion would be, instead of replacing the imports, to use the replace statement in your go.mod while Sprig updates to use the new URL too.

module github.com/evcc-io/evcc

go 1.21

replace github.com/imdario/mergo => dario.cat/mergo v1.0.0

After this, remove from go.mod all the other references to mergo, and run:

go get -u
go mod tidy

It's possible that it will return a different warning, but it makes sense:

go: finding module for package dario.cat/mergo
go: found dario.cat/mergo in dario.cat/mergo v1.0.0
go: dario.cat/mergo@v1.0.0 used for two different module paths (dario.cat/mergo and github.com/imdario/mergo)

  • 👎1
  • 👀1
andig commented

@darccio the vanity url is still showing an empty page.

regnaio commented

@andig I can't revert the vanity URL without causing major issues. The change was announced one month before through an empty release, and the community has updated with no major issues.

Does the move to dario.cat pose any security or transparency issues? When importing a package from github.com/, you know that the code you're importing will reflect the code in GitHub, which should make it harder to sneak in malicious code. How can we guarantee and trust that importing from dario.cat will perfectly reflect the code in GitHub?

I'm unsure if the change to dario.cat was a beneficial move for all.. I hope the trend doesn't continue where packages with wide reach are moved to custom domains

  • 👍1
darccio commented

@regnaio The main reasons to move to dario.cat are:

  • I joined a new company where I work with a very public profile, and I wanted to change my username.
  • In the long term, it gives me the freedom to move the code to another Git hosting provider without introducing future breaking changes.

Both reasons make a compelling case for a vanity URL. A decision that I took after a few weeks of thinking about them and announced through a dummy release a month before the switch.

Concerning security and transparency issues, I think there are none. The vanity URL is just a glorified redirection. You can independently check the response from dario.cat/mergo to see if it points to GitHub.

If you really think it's easier to sneak malicious code onto my domain than onto GitHub, I'd really appreciate what kind of attack you have in mind.

Circling back to trust, you can find the domain linked in my GitHub account, as well as in other social networks of mine.

andig commented

I agree on security. The vanity url is just one more piece that might break in the chain. But that is not sufficient to make it a bad thing as such.

anbrsap commented

My suggestion would be, instead of replacing the imports, to use the replace statement in your go.mod while Sprig updates to use the new URL too.

...

It's possible that it will return a different warning, but it makes sense:

go: finding module for package dario.cat/mergo
go: found dario.cat/mergo in dario.cat/mergo v1.0.0
go: dario.cat/mergo@v1.0.0 used for two different module paths (dario.cat/mergo and github.com/imdario/mergo)

This is not a warning, but an error and prevents go mod tidy from doing other necessary changes:

$ go mod tidy -v || echo failed
go: finding module for package dario.cat/mergo
go: found dario.cat/mergo in dario.cat/mergo v1.0.0
go: dario.cat/mergo@v1.0.0 used for two different module paths (dario.cat/mergo and github.com/imdario/mergo)
failed

So the only option I see is to keep the indirect dependency to github.com/imdario/mergo as long as it's still referenced by your module's dependencies and ignore the proposed update to v1 each time when updating dependencies.

andig commented

The replace directive works fine for suppressing the error. The bad thing is that downstream users of your code will still get the error and need to replace themselves. Absolute nightmare :(

  • 👍6