Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

Support common source archive formats #458

Closed
iand opened this issue Apr 22, 2017 · 7 comments
Closed

Support common source archive formats #458

iand opened this issue Apr 22, 2017 · 7 comments

Comments

@iand
Copy link

iand commented Apr 22, 2017

I proposed this in the Go issue tracker as golang/go#19614 but it was put on hold pending a solution from dep. Since that's likely to be in the medium to long term I thought I'd better open this as a tracking issue so it doesn't get lost.

Summary from that issue:

Currently the go get command expects to interact with a source control system to check out source code. There is no way to package up a source archive (e.g. tar or zip) and use go get to retrieve this.

This proposal would modify the go tool to look for a source archive according to a to-be-defined scheme when the user types go get package. The go tool would download and unpack the source archive in the correct location. Alternatively the go tool could be modified to keep the archive file and support reading source from the archive directly during a build.

@sdboyer
Copy link
Member

sdboyer commented Apr 24, 2017

I was actually just thinking about this over the weekend. Specifically, what a tar archive might look like (the need for supporting alternate source types has been clear to me for a long time). There's a ton of value in doing this, to the point that it might even be necessary for some possible long term changes - for example, the source cache in my current big-picture sketch.

This hasn't been on my immediate TODO list because we have more pressing problems, but if it's something you're interested in working on, I'd love to help you work out a spec.

@iand
Copy link
Author

iand commented Apr 28, 2017

I'll work on an initial draft of a spec for discussion.

@sdboyer
Copy link
Member

sdboyer commented Apr 28, 2017

Aaaaawesome. If you're able to take into consideration some of the issues raised in the aforelinked gist, as well as have a look over #121, that should cover many of the concerns I think relevant, and might make discussion of an initial draft more productive.

I'm also happy to hop on voice/vid to discuss anytime, if you'd find that helpful!

@sdboyer
Copy link
Member

sdboyer commented May 13, 2017

How's this going?

@sdboyer
Copy link
Member

sdboyer commented Aug 28, 2017

gonna close this out - feel free to reopen if you find time to write up the spec!

@sdboyer sdboyer closed this as completed Aug 28, 2017
@aajtodd
Copy link

aajtodd commented Oct 3, 2017

This feels like it would be very useful, perhaps consider re-opening for better visibility if someone looking to contribute picks it up?

@iand
Copy link
Author

iand commented Oct 3, 2017

I'm still interested in the topic, but no actual time to work on it right now so it'd be great if someone else were able to progress it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants