Agree with previous sentiments, and:
On 17-04-18 10:59 PM, Christopher Hall wrote:
You should use built in golang vendoring to ensure these
dependencies, as their is no guarantee that someone won't update the
library port and your app would break, so doing that is very fragile
Currently the GH_TUPLE method is working as it specifies exact
dependency versions or specific git hashes.
but we made several attempts at submodules in vendor dir
but have had problems building and go get -u breaks things.
I am wondering if you might suggest a tool or do any other programs in
ports use such a dependency tool. Last time I searched ports tree I
only saw GH_TUPLE used so I just followed that method.
From my point of view, the only thing that should be in the
vendor directory on checkout is the version-lock file. This is
different for different tools.
I have been using gb, as it makes the most sense to me:
https://getgb.io/
sysutils/hfm uses this
godep is also popular, from what I understand:
https://godoc.org/github.com/tools/godep
Vendoring changed internally in go with a GO15VENDOREXPERIMENT
build environment variable (and then default in 1.6), although I
have not yet played with it:
https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJwkfpx90cqG9AFL0JAYo/edit
... from the docs, it sounds like it would be compatible with gb
from a build standpoint - and you simply could use gb to track,
fetch and lock versions in development - the same thing the ports
GH_TUPLE covers. What you do when it's not hosted at github,
well....
Derek
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
