import (When 'go get' clones what it thinks of as an ordinary repo, the gopkg app will init a new repo, fetch data from github, merge the specified tag into master, and serve up this new repo to the client. This way we can install a package locked to a particular tag without modifying go get's behavior.
"gopkg.herokuapp.com/github.com/someuser/somerepo/tag/sometag/somerepo.git")
Personally, I think it's a mistake in the long run to ignore versions of dependencies the way Go tries to now. Well, it might be ok of a system outside Go helps out, but it shouldn't be all manual work.
One potential chicken and the egg problem with this is that if you want people to use it, it should be quite reliable and unlikely to disappear soon.
Notes:
- Currently gopkg is a Ruby application based on grack, because there is no Git HTTP server implementation in Go.
- It only supports github right now, but would not be hard to add other VCS.
- No effort is made at sane caching - repos are created in temp space, which is not persistent on heroku. Does not attempt to clean up repos - but does recreate them if they are >120 seconds old.
- Might have performance issues for very large repos?
If folks like the idea, I'll register gopkg.io and host it there so the import names are shorter.
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Would this work with mercurial as well, does it have tags similar to git that could support such a scheme?
I really like the decentralized nature of this, I always saw that as a bonus of the current "go get" way. Also, as a lib writer all you'd have do do is start taging, or perhaps not, I suppose you could depend on a "commit" as a version.
Importing a "versioned" path and the real thing (or another versioned path) from different places in a project or dependency tree will result in duplicate inits running, and you can't use values from one with values from the other. Again, a non-starter for me.
One potential chicken and the egg problem with this is that if you want people to use it, it should be quite reliable and unlikely to disappear soon.
The same could happen with e.g. multiple versions of a database/sql binding which register themselves in init.