search

ipfs / go-dnslink

dnslink resolution in go-ipfs
MIT License
55 stars 17 forks source link

Convert to a wrapper around modern dnslink-std/go #15

Open martinheidegger opened 3 years ago

martinheidegger commented 3 years ago

:wave: As part of the grant I am working on I have been preparing a thorough test suite for dnslink to make sure that different dnslink implementations work the same way. I am currently planning to send a PR to this repository that makes it compatible. As part of this process I have been wondering if this repository shouldn't be moved to the dnslink-std organization?

Note: I invited @jbenet as organization owner. (cc. @lidel)

lidel commented 3 years ago

iirc moving go package is extra tricky due to the way imports work in golang (based on URL).

@aschmahmann do you know if we did this before? Any traps to watch out for?

martinheidegger commented 3 years ago

I believe that github redirects renames. An alternative would be to make this repository a shallow wrapper for dnslink-std/go

aschmahmann commented 3 years ago

Is the idea that we'd like this package to be imported in the future as github.com/dnslink-std/go-dnslink?

If so then IIUC GitHub redirects won't be enough since the go.mod file declares the import path of the module and so changing in the new repo would break existing users.

Probably the "most correct" and least breaking thing you could do is transfer the repo to the new org and then create a repo here that wraps the other one while marking all exports as deprecated and then archiving it. This would allow you to support the old import paths, the new import paths, keep the GitHub history (e.g. issues) associated with the new repo, and encourage people to switch their dependencies.

However, I'm not sure who is depending on this repo, so it might be that just doing the transfer is fine 🤷.

martinheidegger commented 3 years ago

Probably the "most correct" and least breaking thing you could do is transfer the repo to the new org and then create a repo here that wraps the other one while marking all exports as deprecated and then archiving it.

:+1:

However, I'm not sure who is depending on this repo, so it might be that just doing the transfer is fine 🤷.

Playing it safe seems better to me.

lidel commented 3 years ago

@marten-seemann if you prepare the "wrapper" repo somewhere, I can do the moving (move this one to dnslink-std and your wrapper in its place)

marten-seemann commented 3 years ago

However, I'm not sure who is depending on this repo, so it might be that just doing the transfer is fine 🤷.

Looks like there's only one project depending on this: https://github.com/search?q=ipfs%2Fgo-dnslink. Given that, creating a wrapper seems like overkill to me, as long as we ping https://github.com/natewalck/go-ipfs-dnslink (or maybe even better, send them a PR).

lidel commented 3 years ago

@marten-seemann oops, I meant @martinheidegger (ugh, autocomplete) but :heart: for checking :pray:

I also found https://github.com/paulgmiller/zebu/blob/main/backend.go, but that's about it. My only worry is private code that we don't see, so let's do the wrapper that prints deprecation warning urging people to migrate.

@martinheidegger I'm parking this for now, lmk when you have time to prepare a "wrapper" just in case, I'll do the moving.

martinheidegger commented 3 years ago

Update on the situation: https://github.com/ipfs/community/discussions/560#discussioncomment-939112