feat(bundle): optionally displays labels associated to a bundle

[fredbi]

• fixes Datamon bundle list should include labels #235

Signed-off-by: Frederic BIDON frederic@oneconcern.com

Note to reviewers

This I consider an early experiment to gauge competing ideas about how to deal with CLI features that pertain to the "porcelain" layer.

While I am all in for some DSL approach that would eventually result in neater code, I have difficulties figuring out how it would actually look like.

This PR plays here the devil's advocate and is my 2 cents contribution to this interesting debate about implementing porcelain, with some code-grounded facts. No big deal if this PR is discarded....

I wanted to figure out a more accurate idea about how much of code/complexity such user requirements actually entail when implemented with the basic tooling the CLI is currently providing.

Regarding expected results, I followed the approach recommended by @ransomw1c in #235 (";" separators) and did not try to over-engineer it with some asynchronous fetching of labels.

[ransomw1c]

just reading the note to reviewers.

the thing about calling this a "porcelain layer" change is that it's actually using some additional "plumbing," core.ListLabels, that wasn't previously consumed by the cmd/ package.

if this deduped and re-used the list labels functionality such that the bundle list and list labels relied on literally the exact same data path to retrieve labels, then i think it would be clearer why the requirement could be implemented independent of adding the additional getLabels porcelain to the pkg/ ListLabels plumbing.

however, as i say, i don't think this a pure porcelain change. it's like if we were shipping async def someFunc() in some alternative universe where the cli was implemented via python bindings, then started shipping def someFuncSync(). even if the data paths of someFunc and someFuncSync are pretty much the same under the hood, that's not an api guarantee. from downstream, they're separate functions. or at least the water is murkier than it would be in the situation described in the previous paragraph.

---

possible takeaway of the preceding rant: refactor core.ListLabels into cmd/?

[fredbi]

Re remark on python bindings

@ransomw1c on the slack channel I posted a proposal about figuring out some python bindings (I've done that in the past, binding python 2 and 3 to a go lib, so I could do this again). This could really be a nice thing, but I didn't receive any comment on that post.

[ransomw1c]

quick note on collective opinions here: after discussion with Joao last week, i suppose it's better understood that my remarks about shipping a Python api to access Datamon functionality in addition to the cli api are purely motivated by attempting to fulfill feature requests related to the cli api without turning cmd/datamon/cmd into spaghetti, and of course we'll all agree that we don't want spaghetti.

at the same time, there are ways to keep cmd/datamon/cmd maintainable without negotiating cli feature requests into a Python api – refactoring cobra use or using a different cli lib altogether to name a couple.

supposing tentative plans for the couple weeks (see Jira RES-1809) occur, one possible scenario – a likely one, even, imo – is that we'll continue to cruise toward cutting v2 with a mild amount of tech debt in datamon/cmd and meanwhile condense hack/fuse-demo/wrap_datamon.sh (note that this prototype we're about to ship to production is still in fuse-demo/, btw) into a (hopefully much terser) Python script.

so i'll propose to continue worrying about the maintainability of cmd/datamon/cmd, except only to first try to make it more maintainable using golang only. meanwhile, there will be some Pythonic faceting of the binary for a totally different raison, the maintainability of the sidecar. and, imo, writing the Pythonic faceting for that purpose could also help get clarity on using python as a means to make the desktop CLI more maintainable.

[kerneltime]

We can park the branch for now. We need to think more about this feature.

[fredbi]

@kerneltime sure. I wanted to close it to. Ransom did rightfully point out that this should go as porcelain. Organizing the porcelain layer is going to be the big code shuffle that will come together with the python SDK.