Vendor with specific tag / commit? about gb

[davecheney]

Gb vendor is just a proof of concept at the moment, it just shells out to go get to help bootstrap your project.

It would be nice to teach it about tags and versions, possibly so I can be used to update an existing vendored package.

For the moment the work around is to fetch the source manually.

+help wanted

[elithrar]

Are you open to the idea of gb being able to:

• Work for libraries? i.e. someone can fetch my library and all deps and
  (should they wish to) use gb build mylib to use those deps instead of
  what's on their global GOPATH?
• Store a reference to those tags in some kind of .vendordotfilething?
• etc?

I write more libraries than 'package mains' but being able to provide a
reproducible version would be extremely useful. The workflow would
probably be go get (which should fetch the vendor/ path too) and then gb build to build off ./vendor.

On Thu, Apr 30, 2015 at 10:43 AM Dave Cheney [email protected]
wrote:

Gb vendor is just a proof of concept at the moment, it just shells out to
go get to help bootstrap your project.

It would be nice to teach it about tags and versions, possibly so I can be
used to update an existing vendored package.

For the moment the work around is to fetch the source manually.

+help wanted

—
Reply to this email directly or view it on GitHub
#17 (comment).

[davecheney]

Matt, can you please make a new issue for this. I want to address this
separately.

On Thu, 30 Apr 2015 09:06 Matt Silverlock [email protected] wrote:

Are you open to the idea of gb being able to:

• Work for libraries? i.e. someone can fetch my library and all deps and
  (should they wish to) use gb build mylib to use those deps instead of
  what's on their global GOPATH?
• Store a reference to those tags in some kind of .vendordotfilething?
• etc?

I write more libraries than 'package mains' but being able to provide a
reproducible version would be extremely useful. The workflow would
probably be go get (which should fetch the vendor/ path too) and then gb build to build off ./vendor.

On Thu, Apr 30, 2015 at 10:43 AM Dave Cheney [email protected]
wrote:

Gb vendor is just a proof of concept at the moment, it just shells out to
go get to help bootstrap your project.

It would be nice to teach it about tags and versions, possibly so I can
be
used to update an existing vendored package.

For the moment the work around is to fetch the source manually.

+help wanted

—
Reply to this email directly or view it on GitHub
#17 (comment).

—
Reply to this email directly or view it on GitHub
#17 (comment).

[andrewchambers]

Imo a plugin which tackles source packaging and library version compatibility via a package file might be cool. Something like cargo/leiningen/maven. It could use a versioned package repo, or just git for everything.

I think there are 3 distinct types of packages. Ones you are just consuming from a fixed version, ones which are libraries with your own patches and changes, and your own application code.

[davecheney]

We could also have a package server to go with the plugin.

That sounds much larger in scope than I imagined, but that's why it's
implemented as a plugin, anyone can write a plugin, they don;t need to be
part of the main gb distribution.

On Thu, Apr 30, 2015 at 11:20 AM, andrewchambers [email protected]
wrote:

Imo a plugin which tackles source packaging and library version
compatibility via a package file might be cool. Something like
cargo/leiningen/maven. We could also have a package server to go with the
plugin.

—
Reply to this email directly or view it on GitHub
#17 (comment).

[andrewchambers]

Yeah, I guess whoever wants to step up can just do it in their own plugin repo. If a plugin gets traction, it can get referenced from the official readme here.

[davecheney]

What I am planning on doing is moving gb-vendor to it's own repository so it can evolve independent of gb. This will happen when I've got the new github pages' site up with updated documentation. I'll close this then.

[davecheney]

gb-vendor has been moved to its own repository, as discussed in #29