search

kardianos / vendor-spec

Go vendor file specification.
90 stars 4 forks source link

Support for directories other than "vendor/" #39

Open akavel opened 8 years ago

akavel commented 8 years ago

(This is kinda counter-issue to #28, attempting to propose a mitigation for the limitations introduced because of it. Also related to #37.)

Before #28, vendor-spec didn't force using the "vendor/" subdirectory for the vendored packages. As much as "vendor/" is now the convention "blessed" in go get etc, third-party tools may still well choose to use a different approach for various reasons (e.g. godep seems to still use Godeps/_workspace/src as of now; also my own tool zpas-lab/vendo uses _vendor/src as of now). As much as I understand the wish to encourage using "vendor/", I don't like that the current wording of the spec seems to force it:

  • The vendor file describes the packages in the vendor folder the vendor file is in.

I believe there's a possibility for a compromise, for example if relative paths were allowed in an appropriate field of the spec (though not sure which field this should be in, now that "local" was apparently dropped... :/ ), while still keeping vendor.json in "vendor/" — for example, maybe something like:

{
     // old "path"
    "import": "golang.org/x/crypto/ssh",
     // "path" is optional, defaults to "./golang.org/x/crypto/ssh", i.e. what is in "import"
     // Alternative name proposals: "location", "dir"
    "path": "../_vendor/src/golang.org/x/crypto/ssh",
    ...
}

Please note, that there's no way on Earth to actually force any tool to use the "vendor/" dir; what the current wording does however, is that it excludes such "non-conforming" tools from possibility of using vendor-spec, with any benefits and unification it could bring.

mattfarina commented 8 years ago

@akavel in Go 1.5+ the vendor directory has special meaning to the go tool. In Go 1.6 the GO15VENDOREXPERIMENT will be on by default. Are you familiar with that?

akavel commented 8 years ago

@mattfarina Yes. But there are still scenarios and reasons where a tool might specifically want not to use it for some or all vendored packages.

davecheney commented 8 years ago

As this is likely to be a very contentious position, would you please enumerate those situations, preferably in detail.

On Tue, 29 Dec 2015, 17:59 Mateusz Czapliński notifications@github.com wrote:

@mattfarina https://github.com/mattfarina Yes. But there are still scenarios and reasons where a tool might specifically want not to use it for some or all vendored packages.

— Reply to this email directly or view it on GitHub https://github.com/kardianos/vendor-spec/issues/39#issuecomment-167830181 .

akavel commented 8 years ago
  1. For zpas-lab/vendo, I've chosen "_vendor/" over "vendor/" primarily in order to keep "./..." a useful package designation, especially for "go test ./...", "go generate ./..." and secondarily also for "go build ./..." and "go list ./...". Potentially also for other third-party tools (gometalinter?) "_vendor/" is "safe by default". When using "vendor/", is it possible to have those commands omit the contents of the "vendor/" tree easily on Windows, where "go test/generate/build $(go list ./... | grep -v '^vendor/')" is not possible AFAIK? (I don't want to have to use MSYS for Go on Windows.)
  2. As far as I can see, e.g. go-gb seems not to use the GO15VENDOREXPERIMENT meaning of vendor/ dir. I suppose putting vendor.json in go-gb's $PROJECT/vendor path could actually work and look like conforming to vendor-spec, but that seems more of a hack (as "$PROJECT/vendor" works around go get's understanding by not being in $GOPATH), and it would anyway break the "is in $GOPATH/src" requirement currently present in vendor-spec. I don't think go-gb's approach can be converted to fit in the GO15VENDOREXPERIMENT structure, but I don't see why it couldn't benefit from vendor-spec; or am I wrong?
  3. As far as I can see, e.g. godep doesn't currently use "vendor/" dir, but "Godeps/_workspace/src". Don't know what their reasons are, and if they plan/will migrate to "vendor/" or not, but they haven't for now. This could at the very least be an argument for supporting legacy tools.

Point 1 above is from my tool, thus I was able to provide reasoning. Points 2-3 are observations after a cursory glance over some (not all) vendoring tools I don't personally use, so don't know the detailed reasoning.

davecheney commented 8 years ago

As to point 1, yeah sorry, we lost that argument.

If you mean gb for point 2, gb doesn't use the vendor support because it isn't based on the Go tool and doesn't use go get. I don't know if that makes the vendor spec more or less applicable.

On Tue, 29 Dec 2015, 19:50 Mateusz Czapliński notifications@github.com wrote:

  1. For zpas-lab/vendo https://github.com/zpas-lab/vendo, I've chosen "_vendor/" over "vendor/" primarily in order to keep "./..." a useful package designation, especially for "go test ./...", "go generate ./..." and secondarily also for "go build ./..." and "go list ./...". Potentially also for other third-party tools (gometalinter? https://github.com/alecthomas/gometalinter) "_vendor/" is "safe by default". When using "vendor/", is it possible to have those commands omit the contents of the "vendor/" tree easily on Windows, where "go test/generate/build $(go list ./... | grep -v '^vendor/')" is not possible AFAIK? (I don't want to have to use MSYS for Go.)
  2. As far as I can see, e.g. go-gb seems not to use the GO15VENDOREXPERIMENT meaning of vendor/ dir http://getgb.io/docs/project/. I suppose putting vendor.json in go-gb's $PROJECT/vendor path could actually work and look like conforming to vendor-spec, but that seems more of a hack (as "$PROJECT/vendor" works around go get's understanding by not being in $GOPATH), and it would anyway break the "is in $GOPATH/src" requirement currently present in vendor-spec. I don't think go-gb's approach can be converted to fit in the GO15VENDOREXPERIMENT structure, but I don't see why it couldn't use vendor-spec; or am I wrong?
  3. As far as I can see, e.g. godep doesn't currently use "vendor/" dir, but "Godeps/_workspace/src". Don't know what their reasons are, and if they plan/will migrate to "vendor/" or not, but they haven't for now. This could at the very least be an argument for supporting legacy tools.

Point 1 above is from my tool, thus I was able to provide reasoning. Points 2-3 are observations after a cursory glance over some tools I don't personally use, so don't know the reasoning.

— Reply to this email directly or view it on GitHub https://github.com/kardianos/vendor-spec/issues/39#issuecomment-167852023 .

freeformz commented 8 years ago

:-(. FWIW: godep will save files to vendor/ if go1.5 && GO15VENDOREXPERIMENT == 1 || go1.6 && GO15VENDOREXEPERIMENT != 0. It still writes it's meta data to Godeps/Godeps.json though in the Godeps format. This is primarily for backwards compatibility. At some point I'd like to change things and put the spec file in vendor/ as vendor.json, conforming to this spec (plus some extra identifiers). But ATM I have too many other things on my plate.

akavel commented 8 years ago

As to gb and vendor-spec: from what I remember (or was I over-interpreting?), vendor-spec was initially created with intention of supporting not only the tools "doing the vendoring", but also potentially tools helping with some stuff "after the vendoring is done". Examples of tool ideas fitting in the latter category:

I believe it's extremely valuable to keep vendor-spec in such a shape, that it can facilitate using such "post-vendoring" tools with as many "do-vendoring" tools as possible. That's also how I believe gb could benefit from supporting vendor-spec. But without #39, this venue is closed for "do-vendoring" tools which don't fit purely in the GO15VENDOREXPERIMENT structure, such as gb or vendo.

kardianos commented 8 years ago

@freeformz BTW, in the go1.6 tree, I made a change to the go tool so that go env will show either a "1" or "0" (never bank) that reflects the internal state of the go tool.