-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
list tool support on front page #35
Comments
@rsc I suspect "kardianos/govendor" (previously "kardianos/vendor") is the only one that tries to track it. Owen's nut had tentatively said he might make use it as a "lock" file and the toml file as human editable, but I haven't seen it move in that direction. Godep has altered it's dep list file, but hasn't made moves to the vendor-spec as far as I know. With the vendor folder experiment (no import path rewrites), the role of the vendor-spec is in my mind to record a package with a revision, and maybe a version, plus be in a format where other properties can be recorded too. Other then just being different then what people might have written themselves, there appear to be two main issues:
|
I've got a conversation with Edward who has worked on Godep and I am trying to understand the rational for Godep's spec file. I'll post here issues other tools has as I understand them. |
The gap, as I feel it exists anyway is:
w/o this data somewhere reproducible builds are impossible. I was hesitant to raise issues for these use cases as I feel that the vendor-spec's focus is on vendoring code, not enabling reproducible builds, of which vendoring is only part of. |
PS: I'd be happy to report issues if you disagree. My plan wrt godep was to wait to see what happens with the vendor-spec and probably adopt it for package meta, but either keep a Godeps.json file around somewhere else or since it's json, just add the keys godep/myself need directly to the file. |
@freeformz I wouldn't be against a complementary spec that can be overlaid on the vendor-spec that will contain enough meta-data to achieve reproducible builds. If we did decide to specify this, I would want to keep them separate. Some tools may decide to just use the vendor-spec, others will go further and also use the full reproducible-build-spec (a superset of the vendor-spec). I would want buy in from others, but I think that would be a reasonable way to approach it. |
I'm fine with that although I'm not convinced it's worth specifying 3 fields. As it is the vendor-spec isn't all that different from the On further inspection of the vendor-spec examples I'm not sure I could actually use the spec with |
@freeformz Give me a day. It is slated for some changes. As previously stated, the arity of record is different between godep and vendor-spec. |
@freeformz I've made the changes, please examine to see if we can merge. @rsc I haven't updated kardianos/govendor to use path and origin yet. After I have done so I'll add a new section for tools that implement this. |
@kardianos Link to a PR? |
Please examine the spec to see if we can merge what govendor and godeps writes down. The most recent commit is here: |
What tools understand vendor.json and can be expected to work with it? I don't actually know. I saw reference to Daniel's govendor earlier, which was the first I'd heard of it. I think maybe nut supports vendor.json. I thought godep did but now it looks like maybe it just supports the vendor/ directory tree, not vendor.json itself. Some clarity on what tools to use to try "vendor.json" out would help. Maybe it would encourage others to update their own tools to use it too.
The text was updated successfully, but these errors were encountered: