I would like to take this up and work on it.

Sounds good. Assigned.

The expecttation is to add optional node after kit info command to display specific node. If nothing is mentioned full info needs to be displayed. Works?

We can introduce a filter flag --filter so
kit info displays the full info
kit info --filter .model.path prints only the model path.

Quick question. Can I use yqlib package to acheive the same or has to be developed in house?

I would be open to a PR that used yqlib, though I suspect it may be a bit of using a sledgehammer to drive a nail situation. The library is capable of a lot of manipulation, and we're really only concerned with simple access at the moment.

I'll be building something custom then. Any approach or suggestions?

@amisevsk Using reflect package I've tried adding the functionality. Need guidance with some of the pending items.

• What to do if the filter if a struct, e.g., -f model. I'm able to fetch the struct should I display in YAML or show an error?
• Suggest if I'm missing something or refractoring is needed.

@srikary12 I haven't looked into it too much, but I figure that since we have the unmarshalled struct (i.e. the Kitfile) we should just use the filter to walk that struct and marshal the resulting field.

Suppose the user passes -f ".model" (c.f. kit info <model> | yq '.model'). Then the Go code would look something like

// config := <resolved Kitfile from ResolveManifestAndConfig(...)>
filteredField := config.model

buf := new(bytes.Buffer)
enc := yaml.NewEncoder(buf)
enc.SetIndent(2)
if err := enc.Encode(filteredField); err != nil {
  // handle err
}
fmt.Println(string(buf.Bytes()))

(This assumes that using reflect to walk the struct is... simple enough. I've been working in TypeScript lately so I forget how marshalling reflected structs works :) )

Again, though, I haven't tried it out myself so I may be missing something. If this is looking ugly or difficult, feel free to submit a PR using yqlib and I will review. The reason for my gut take on yqlib is that it's designed to handle arbitrary yaml and parse it, whereas in our case we have a defined structure to work with -- I'm very ready to be wrong here :)

I'll the required changes and mark it for review. I've expected the same inputs from you. I'll have to marshall them and display.

Thanks for the inputs.

Fixed it :) and raised a PR.