x/vgo: access to details of packages etc #23951
Comments
|
Please don't fork internal packages. We're going to build out a good command-line API for getting this stuff out of the go command directly. It's only day 1. :-) |
rsc
changed the title
|
Wait - not sure you understand my request... I'd like to trigger the go commands from code, not a command line tool... e.g. zipbuf := &bytes.Buffer{}
gotool.GetModule(zipbuf, "github.com/foo/bar")
// downloads module zip and writes to zipbuf |
Totally understand it's just a prototype! |
Sorry, but I'm not willing to support Go API access, because then if you have a stale tool then your tool will do old things. In contrast if your tool runs the go command-line to find out what it needs, then it will not need to be updated after and stay in sync with each Go release. We're going to work on command-line API, as I said. |
|
I understand. It's a whole different level of effort maintaining a backwards compatible API than a command line tool. Thanks for looking into this. |
It would be great to have API access to some of the internals of the new
vgotool.I recently spent a good deal of time forking
go getand replacing the calls togitwith thego-gitlibrary, so I could get a package and dependencies to memory rather than the filesystem (see here). It was neither fun nor pretty.The new architecture of removing the external tools and transferring zip files around over HTTP lends itself rather well to this... I'd love to be able to stream a module zip file to a io.Reader without having to fork internal packages.
The text was updated successfully, but these errors were encountered: