cmd/go: remove legacy conversions

[rsc]

The go command contains code to automatically populate go.mod during 'go mod init' using the metadata from various now very old, outdated Go dependency managers. The code is complex, so it needed a good test (testdata/script/mod_convert.txt), which fetches very old versions of various actual packages.

The code has little benefit today, as it can only possibly work on ancient programs, and everyone who was going to update to Go modules has done so at this point. At the same time, the test is now one of the longest tests in cmd/go. We pay a high cost for this code that no one needs anymore.

Let's just delete the code and the test.

[rsc]

/cc @bcmills @matloob

[oiooj]

Since I am also involved in the development of mod conversions, I‘d like to do this work.

[mvdan]

Should we somehow point users trying to convert to modules to the latest Go version that still supported that automation in go mod init? It would likely still be better than doing it by hand for some time.

[bcmills]

Not to mention, the conversion code had some bugs and never really worked properly to begin with (see #33406, perhaps others). 😅

[earthboundkid]

May I suggest extracting the code from the go tool and dumping it into some repo where it can be independently installed?

A party trick I sometimes do is take a small project that I wrote in 2018 and show that it can be upgraded to the current version of Go in less than a minute, while the JavaScript dependencies in the project basically can't be installed at all, let alone upgraded. I would hate for my trick to stop working. :-) More seriously, it would be nice to leave some liferaft for anyone who finds themselves handed an important but abandoned bit of Go software for their organization.

[bcmills]

@carlmjohnson, there are enough differences between modules and the legacy dependency-management tools that a straight conversion often isn't valid anyway (due to unsupported pinning behaviors, or module dependencies that were not seen by the legacy tools, or differences in module vs. package or repo granularity).

Generally, go mod tidy -e should give a good enough rough cut, and go get can be used to fine-tune it from there.

[rsc]

@carlmjohnson Does your program use dep or godeps or one of those? If not, you won't be affected. If so, try deleting the config file from that versioning tool and see how well the go command fares. My guess is the config is not doing much. If I'm wrong, that'd be good to know.

[earthboundkid]

It used dep. If you delete the Gopkg.toml and lock files, it doesn't quite build because of a breaking change in go-chi, but that's the only thing holding it back. The import paths are otherwise enough for a build.