On Mon, Oct 31, 2022 at 8:27 PM mr....@gmail.com <mr.i...@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/CABx2%3DD-006wi7seJowPM0QOCn%2B2XnPPYnVyjwT4fy25hvw_%3Ddw%40mail.gmail.com.
