4 ms·

Can you explain your idea in more detail ?

eternalban 11y ago
Think /.git, Dave. /.go vendors # map simple import name to explicit (ugly) path ... # other stuff for additional e.g. generate features Hierarchical: Think OO-ish shadowing of .go directives and metainfo. Is this clear?
- davecheney 11y ago
  > Is this clear? not really
  - eternalban 11y ago
    # ---------------------------------- # general layout of the land # ---------------------------------- $GOPATH/src/.go $GOPATH/src/.go/config $GOPATH/src/.go/vendors # for all projects # ---------------------------------- # $GOPATH/.go/vendors sketch # ---------------------------------- lib/mq = github.com/lib/pq@master mgo = labix.org/v2/mgo ... etc # ---------------------------------- # specific project 1 # uses the global version of package labix.org/mgo # uses a project specific package hotness # ---------------------------------- $GOPATH/src/mygofoo $GOPATH/src/mygofoo/foo.go $GOPATH/src/mygofoo/.go $GOPATH/src/mygofoo/.go/vendors # ---------------------------------- # foo.go fragment # ---------------------------------- package mygofoo import ( "mgo" // version spec'd in global .go "lib/pq" // version spec'd in project specific .go "hotness" // version spec'd in project specific .go ... ) ... # ---------------------------------- # $GOPATH/src/mygofoo/.go/vendors sketch # ---------------------------------- lib/mq = github.com/lib/pq@experimental // lets pretend hotness = bitbucket.org/wiz/hotness@master ... etc # go tool > cd $GOPATH/src/mygofoo > go build -vendors using: mgo -> labix.org/v2/mgo lib/pq -> github.com/lib/pq@experimental hotness -> bitbucket.org/wiz/hotness@master > # go tool can obviously allow for command line mods of the .go

Think /.git, Dave. /.go vendors # map simple import name to explicit (ugly) path ... # other stuff for additional e.g. generate features Hierarchical: Think OO-ish shadowing of .go directives and metainfo. Is this clear?

davecheney 11y ago
> Is this clear? not really
- eternalban 11y ago
  # ---------------------------------- # general layout of the land # ---------------------------------- $GOPATH/src/.go $GOPATH/src/.go/config $GOPATH/src/.go/vendors # for all projects # ---------------------------------- # $GOPATH/.go/vendors sketch # ---------------------------------- lib/mq = github.com/lib/pq@master mgo = labix.org/v2/mgo ... etc # ---------------------------------- # specific project 1 # uses the global version of package labix.org/mgo # uses a project specific package hotness # ---------------------------------- $GOPATH/src/mygofoo $GOPATH/src/mygofoo/foo.go $GOPATH/src/mygofoo/.go $GOPATH/src/mygofoo/.go/vendors # ---------------------------------- # foo.go fragment # ---------------------------------- package mygofoo import ( "mgo" // version spec'd in global .go "lib/pq" // version spec'd in project specific .go "hotness" // version spec'd in project specific .go ... ) ... # ---------------------------------- # $GOPATH/src/mygofoo/.go/vendors sketch # ---------------------------------- lib/mq = github.com/lib/pq@experimental // lets pretend hotness = bitbucket.org/wiz/hotness@master ... etc # go tool > cd $GOPATH/src/mygofoo > go build -vendors using: mgo -> labix.org/v2/mgo lib/pq -> github.com/lib/pq@experimental hotness -> bitbucket.org/wiz/hotness@master > # go tool can obviously allow for command line mods of the .go