W dniu wtorek, 12 lipca 2016 22:15:29 UTC+2 użytkownik Johann Höchtl
napisał:
> What do others use?
>
Where I work, we've evaluated what was available some year ago, but nothing
fit our envisioned usecases. So we took our time, sit down and meticulously
analyzed what we need, wrote design docs, argued over them hard, and
finally wrote the code. Since then, we've never looked back, it just works
for us, we don't even think about it as a problem anymore. We've even
open-sourced it; but we didn't advertise, because we weren't at freedom to
add the final, yet so important touch: of writing a proper readme... I find
it extremely unfortunate and painful from point of view of this project,
but internally we had to quickly shift our gears and really focus on much,
much more important stuff - which still keeps us really busy.
But enough explaining myself; what I'd really like is to summarize pros &
cons of the tool below, plus add some links for further reading for anyone
interested:
Features:
- main command "vendo recreate" analyzes all .go files in your repo, across
all build tags and platforms; then recursively analyzes all their external
dependencies (now assuming only predeclared platforms and default build
tags). Whole repos (because LICENSE & consistency) are copied into _vendor/
subdir (because `go test ./...` & `go build ./...`), registered in
vendor.json (older version which still supported our approach) with
revision ID and precise date (awesome in cases like code.google.com winding
down and everyone going hg->git). Git, hg, bzr are supported as source
repos (more can be easily added). Code from vendored repos is `git add`-ed
automatically, ignoring .git/.hg/.bzr dirs; unused repos are detected and
auto-removed.
- private patching is explicitly supported by design ("comment" field in
vendor.json should be updated with patch description); though public forks
are practically superior and more encouraged.
- `go get -u` functionality is supported via "vendo update". Selected
upstream repos are cloned based on info in "vendor.json", then updated as
expected.
- permissive BSD license (3-clause).
Limitations:
- does not currently use the "canonical" vendor/ directory structure, thus
requiring: `GOPATH=$ROOT/_vendor:$GOPATH`. Reasons: mostly for ease of `go
build ./...`, `go test ./...` etc; also vendor/ was not yet certain when we
did it. TODO: support vendor/ and add some helper wrapper for ./... ?
- no README yet. Sorry :(
- uses older version of vendor.json specification (many changes were done
later, while ignoring backwards compatibility, and we noticed them much too
late);
- currently supports only git as the "master" VCS;
- we planned for some helpful `git commit`-time hooks, but didn't implement
them yet; lack of them doesn't really hurt us enough that we could with
straight face allocate some time for it; at least for the time being.
More details:
- the original use-cases design doc:
https://github.com/zpas-lab/vendo/blob/master/use-cases.md
- example results:
https://github.com/zpas-lab/vendo/blob/master/vendor.json
https://github.com/zpas-lab/vendo/tree/master/_vendor
- the main repo: https://github.com/zpas-lab/vendo/
NOTE: If anyone has questions, you're very welcome, but *please* make sure
my email is in CC. Unfortunately I don't have enough time now to check
golang-nuts regularly :/
Best Regards,
/Mateusz Czapliński.
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
