Go based CLI

[dakaneye]

Go seems like a better fit for a CLI tool than Python. We could make improvements around performance, code structure/readability, delivery (binaries!), testing, and async processing (where applicable).

Probably dependent on a Go SDK for the API, but wanted to enter this explicitly as something to discuss.

[alfredodeza]

Perhaps if the direction+objectives are clear it would help to get better questions to help guide efforts.

For example, is delivery a problem with the anchore-cli today? We deliver this tool from the container. Is performance currently an issue? Most of the work happens on the remote API.

[dakaneye]

@alfredodeza I'm reticent to say that delivery is a problem, but I think delivering the CLI as part of the container isn't necessarily the right thing to do when that container is running the application. Installing from Pip is also okay but requires people to have python installed (they probably already do).

Ideally, people could install the CLI from their native package managers (yum, apt-get, brew, even curl, etc.) That seems to be the industry standard for delivering a CLI.

Performance probably isn't an issue now but could be, especially as we begin to integrate other services, or if we potentially decided to do client-side processing for a certain task.

Integration of syft and grype into the anchore-cli would also provide a nice user experience (i.e. having all your anchore tools in one place!)

[alfredodeza]

These are all good initiatives to explore, thanks for clarifying.

@alfredodeza I'm reticent to say that delivery is a problem, but I think delivering the CLI as part of the container isn't necessarily the right thing to do when that container is running the application. Installing from Pip is also okay but requires people to have python installed (they probably already do).

Ok, so you are identifying the delivery of the CLI isn't the right thing to do since it is part of the container. But the alternative of installing with pip seems acceptable - is there really an issue? I know that installing via pip has its challenges as well. Some container runtimes don't have Python installed, or forces the consumer to select a Python container.

Ideally, people could install the CLI from their native package managers (yum, apt-get, brew, even curl, etc.) That seems to be the industry standard for delivering a CLI.

Packaging for Deb/Rpm has all other set of warts that are tricky to get right: repositories, signing keys, adding repos locally to install, etc...

Brew is a little bit more straightforward as it is curl. Again, I think we need more clarity here as to what the issue is. For example, it could be "consuming of the anchore-cli should be separate from the container, and an installation method that doesn't require Python should be preferable for $reasons".

Performance probably isn't an issue now but could be, especially as we begin to integrate other services, or if we potentially decided to do client-side processing for a certain task.

I would like to start addressing a performance problem when/if it arises. It is difficult to improve performance without a solid baseline to compare with. From what I see in this ticket, it seems like the performance is not a concrete problem to solve yet.

Integration of syft and grype into the anchore-cli would also provide a nice user experience (i.e. having all your anchore tools in one place!)

The anchore-cli talks to the Anchore Engine / Anchore Enterprise over HTTP. What kind of integration are you envisioning for syft and grype? Something like a Golang SDK that syft and grype can use? Or something else?

[dakaneye]

Thanks for the response @alfredodeza this is a really good discussion.

But the alternative of installing with pip seems acceptable - is there really an issue? I know that installing via pip has its challenges as well. Some container runtimes don't have Python installed, or forces the consumer to select a Python container.

Great point, pip does work well as long as you have python installed, which to me is the main point of having a nice little go binary that can be super portable. If you want to run it in a container, go for it! If you don't....go for it!

I definitely hear you about packaging for Linux distros being a PITA. That's something we would have to deal with either way (regardless of which language we choose) if we want to improve the UX of installing the CLI. My thinking here is mostly focused on, doesn't matter which Linux Distro are you using or what dependencies you have installed, it should be super easy to deliver the CLI.

Re: performance, I see where you're coming from. I always preach that "pre-optimization is the root of all evil". However, my thinking is that there is a little more flexibility and room for improvement with go versus python with respect to performance. Asynchronous & Concurrent operations are much easier to build and maintain in a Go-based application.

It also gives us a bit more of extension options (I was just reading about the kubernetes go SDK, where you can setup informers to watch for events, and seems like something like this could translate nicely to an Anchore SDK)

Integration via SDK is a great option, but with cobra, we can also embed the syft and grype utilities into the actual SDK as sub commands. That would be a neat way to give customers a uniform experience using our tool.

The last point I'll add is that Go does have a bit more popularity, and similarly to the toolbox project, it might be a way to get more community involvement re: development.

[zhill]

Typically the challenge we've had with python is lib conflicts with other parts of the system and users not knowing of being comfortable with things like virtual environments. More advanced users are usually ok, but folks not used to managing python stuff can get tripped up and we've seen struggles getting things to work on Mac or Windows laptops where versions or other env factors can cause issues due to lack of isolation of the dependency-chain of the CLI. There may be another way to solve that as well, but I'm not sure what the level-of-effort is for that for us or users.

Performance isn't an issue because as-is the CLI doesn't do anything more than send some requests and format output.

I'd also like to be able to get the UX of our CLI closer to that of syft/grype but that doesn't strictly require a language change, there are just established patterns we have in those tools and libs that could be potentially re-used.