Why using govc CLI instead of govmomi?

[shaominchen]

This question was raised in a PR review discussion: #1585 (comment)

Why are we not using govmomi directly? Is it because govc CLI is easier to integrate with?
@shuklanirdesh82 @msterin

[govint]

One advantage of using the CLI vs. govmomi is the test code is simpler from not having to traverse the object hierarchy and hence more code to fetch data. At least that part of the test code is really small now with only command invocation and output parsing in use.

[msterin]

yeah, but it does screen scraping, , doesn't it ? Or does govc spit out xml or json ?

[govint]

Json format is what we do today for the few commands used.

[shuklanirdesh82]

In addition to #1586 (comment) (Thanks @govint ) .. the reason behind leveraging govc to keep in sync with other CLI approaches; we are using docker CLI, admin CLI so thought it would be better and lighter to use govc CLI. govc has argument support for -json=false|true (by default) and json parser that we use to grab the require output.

[shuklanirdesh82]

As per my understanding importing govmomi libraries requires to add entry to vendor folder, better to avoid for testing effort. If there is a strong opinion on using govmomi then we leave this issue open and enhance out test libraries in the future.

Please feel free to correct me about adding entry to vendor for dependency is not correct.

[msterin]

1. I don't see a problem in adding govmomi to ./vendor. We already have plenty there.
2. we are using 'docker' CLI because allegedly it gives us a better test coverage and "user" experience. I am not sure I agree, but docker CLI does wrap up sequences of API calls so it makes sense to check them.
   same args to not apply to govc. We do not have "other CLI approaches"
   3.with intermediate json, govc is OK, so I am fine if you close

[shaominchen]

Closing this as per above discussion - we don't have strong motivation to switch to govmomi as of now.