https://k8s.io/apimachinery/pkg/util/diff?go-get=1
He needs to add parameters to be able to access https://github.com/kubernetes/apimachinery/blob/master/pkg/util/diff/diff.go#L57 This is his path to realization 在2022年11月1日星期二 UTC+8 12:41:22<kra...@skepticism.us> 写道： > On Mon, Oct 31, 2022 at 8:27 PM mr....@gmail.com <mr....@gmail.com> wrote: > >> Yes, it is very rare, but it can be encountered, and once encountered his >> workload will be a lot of >> >> github.com/pkg/errors > std.errors >> ioutil.TempDir => os.MkdirTemp >> ioutil.ReadAll => io.ReadAll >> > > You seem to agree with me that such refactorings are extremely rare. > Furthermore, your ioutil.TempDir to os.MkdirTemp example is a trivial > substitution since the API didn't change -- only the preferred function > name changed. How many programs include more than a single call to the now > deprecated ioutil.TempDir function? And how much work is it for the people > maintaining those projects to manually make the required substitutions? How > much work would be saved even if those people were aware of such a tool? > > Your real question seems to be "Is there a tool that replaces a deprecated > API with the preferred API?" I am not aware of such a tool. Furthermore, > such a tool would have to be aware of the minimum Go version supported by a > project and whether a particular dependency can be updated. The mechanical > substitution of the API is trivial compared to determining whether the > substitution is appropriate. Also, the substitution is only possible if the > API is unchanged -- only the preferred symbols are changed. > > I also note that none of the links in your initial message are valid. So I > can't determine whether they are a trivial renaming of an API or the > changes are more substantive. > > > 在2022年10月31日星期一 UTC+8 10:52:45<kra...@skepticism.us> 写道： >> >>> I'm curious how often you perform such refactoring? In my experience >>> such changes are extremely rare and usually require other changes due to >>> differences in the API of the two third-party packages . Which means, in my >>> experience, expending effort to automate such import rewrites typically >>> requires more effort than just doing it "by hand". The gomvpkg tool is >>> meant to solve a more common problem that does happen with some regularity. >>> Namely, changing the paths of packages private to a particular project as >>> that project evolves. Which is why that tool "doesn't get the job done" for >>> your situation. >>> >>> On Sun, Oct 30, 2022 at 7:22 PM mr....@gmail.com <mr....@gmail.com> >>> wrote: >>> >>>> He doesn't get the job done. >>>> >>>> 在2022年10月22日星期六 UTC+8 06:20:53<Amnon> 写道： >>>> >>>>> try https://pkg.go.dev/golang.org/x/tools/cmd/gomvpkg >>>>> >>>>> >>>>> On Friday, 21 October 2022 at 16:58:57 UTC+1 mr....@gmail.com wrote: >>>>> >>>>>> I'm looking for a tool like this, I've searched google and github and >>>>>> can't find one, have you guys used such a tool? >>>>>> >>>>>> I use a method like this in my code >>>>>> >>>>>> k8s.io/apimachinery/pkg/util/diff.ObjectReflectDiff >>>>>> >>>>>> k8s.io/apimachinery/pkg/util/diff is his import path, later I want >>>>>> to switch to another method. >>>>>> >>>>>> github.com/google/go-cmp/cmp.Diff >>>>>> >>>>>> github.com/google/go-cmp/cmp is his import path. >>>>>> >>>>>> I would like to ask if there is a more convenient tool for replacing >>>>>> the whole project? >>>>>> >>>>>> k8s.io/apimachinery/pkg/util/diff.ObjectReflectDiff -> >>>>>> github.com/google/go-cmp/cmp.Diff >>>>> >>>>> > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/93e00ff8-1ebd-418d-b07e-8f97ab4e1426n%40googlegroups.com.
