8000 Please add a flag to `dep ensure` to write out a templated file based on current lock state · Issue #1773 · golang/dep · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Sep 9, 2020. It is now read-only.

Please add a flag to dep ensure to write out a templated file based on current lock state #1773

Closed
jmillikin-stripe opened this issue Mar 23, 2018 · 7 comments · Fixed by #1781
Closed

Please add a flag to dep ensure to write out a templated file based on current lock state #1773

jmillikin-stripe opened this issue Mar 23, 2018 · 7 comments · Fixed by #1781

Comments

@jmillikin-stripe
Copy link

Dep's generated gopkg.lock has very useful data for integration with larger build systems, but the TOML format can be difficult to consume from other tooling. It would be nice if dep ensure could take a template file in text/template format, run it with the lock data, and output to a user-specified path.

For example, this would simplify integration with Gazelle because dep ensure could directly generate Bazel repository rules that are in sync with the vendor dir.
@akutz
Copy link
Contributor
akutz commented Mar 26, 2018

Hi @jmillikin-stripe,

I missed this as well, but did you see if the dep status command with the flag -f satisfies your issue?

$ dep ensure
$ dep status -f 'GO_TEMPLATE'

@jmillikin-stripe
Copy link
Author

Not sure -- @sdboyer and I were talking about this last week, and based on my understanding of dep it needed to be in ensure because that was the thing that checked for stray vendor/ files and wrote the lock file.

Sam, can dep status -f do what we want here?

@sdboyer
Copy link
Member
sdboyer commented Mar 26, 2018

yep, I think it can. I'd have to double-check to be certain it covers all our needs, but that's certainly the kind of thing it was designed to do.

@akutz
Copy link
Contributor
akutz commented Mar 26, 2018 •
edited
Loading

Hi @sdboyer,

Actually, it can't. It doesn't have the actual package information, source (if a fork), etc. dep status lacks a lot of the information. I'm participating in a hackathon and we plan to work on this issue as a PR to augment status in a sane way to include this additional information when requested.

@akutz
Copy link
Contributor
akutz commented Mar 26, 2018

Hi @jmillikin-stripe,

Is the use case specifically Gazelle or broader than that? dep status certainly cannot at the moment provide the URI of the repo used to get sources since the fork info is not present in a BasicStatus struct. That's the type of parity our Hackathon team intends to add to dep status tomorrow.

@sdboyer It does seem that dep status is the correct location for a templated output of the Lock file. Would you agree?

@jmillikin-stripe
Copy link
Author
jmillikin-stripe commented Mar 26, 2018 •
edited
Loading

My use case is for integrating with Bazel's Go rules in general, but I'm sure there are others who would like to parse the lock data using (for example) JSON, which can be done with only stdlib.

@akutz
Copy link
Contributor
akutz commented Mar 26, 2018

@jmillikin-stripe,

Well, this is the data available to dep status -f, and you'll note it's missing several pieces of info from the lock file:

// BasicStatus contains all the information reported about a single dependency
// in the summary/list status output mode.
type BasicStatus struct {
    ProjectRoot  string
    Children     []string
    Constraint   gps.Constraint
    Version      gps.UnpairedVersion
    Revision     gps.Revision
    Latest       gps.Version
    PackageCount int
    hasOverride  bool
    hasError     bool
}

For example:

$ dep status -f '{{printf "%+v\n\n" .}}'
&{ProjectRoot:github.com/akutz/gosync Children:[] Constraint:v0.1.0 Version:v0.1.0 Revision:94b0033d0b5fc254594c3174329c19356c2c4f63 Latest:v0.1.0 PackageCount:1 hasOverride:false hasError:false}

&{ProjectRoot:github.com/container-storage-interface/spec Children:[] Constraint:v0.2.0 Version:v0.2.0 Revision:35d9f9d77954980e449e52c3f3e43c21bd8171f5 Latest:v0.2.0 PackageCount:1 hasOverride:false hasError:false}

&{ProjectRoot:github.com/coreos/etcd Children:[] Constraint:v3.3.2 Version:v3.3.2 Revision:c9d46ab3799b7f2174268e75f72d01e6d6aac953 Latest:v3.3.2 PackageCount:7 hasOverride:false hasError:false}

Information missing from a BasicStatus includes:

  • The sub-package names (only the count is retained)
  • The constraint's branch name if the constraint is by branch
  • The constraint's source value if the constraint references a fork
  • The solver metadata (although admittedly I'm not sure how interesting that is to external actors)

There may be more data currently unavailable to dep status, but the above is what I see at first glance. It seems to me that your use case would at the very least require the constraint's source value if it differs from the project name (such as in the case of a fork).

@akutz akutz mentioned this issue Mar 28, 2018
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Support additional details with status command akutz/dep
3 participants
@sdboyer @akutz @jmillikin-stripe
0