Add digests flag to plugin search, which displays SHA values for all os/arch per binary

[datosh]

Changes

• Added --digests flag to flux plugin search

› ./bin/flux plugin search --digests      
NAME    	VERSION	OS/ARCH      	DIGEST                                                                  
operator	0.56.0 	darwin/amd64 	sha256:6f24516ddbb928d6cb5227c6bfdb381c120dea99457eae6fcd69da7fce5a1036	
operator	0.56.0 	darwin/arm64 	sha256:269c0ccfabc98660b99f0dfca80ce1eefb3ced2bc44207a7c4858fba1d3f29f3	
operator	0.56.0 	linux/amd64  	sha256:02f67d15b246b0af01150cd72ac2dcb49e725a8f1b4fa969abef147033803404	
operator	0.56.0 	linux/arm64  	sha256:e05190b97f5cf8b8e80c0ece2cdc5b7d49f4cf09206800adadf5b9f2f635c486	
operator	0.56.0 	windows/amd64	sha256:6aedc33471fb658075f6b3c979c72abf6647c096058b3b8bc4732c5d4b878791	
operator	0.56.0 	windows/arm64	sha256:bb11767b5bf3e57c17ec89f776d4dfc8d9dcde35d4782aa0d50e4ef99ca65642	
schema  	0.11.0 	darwin/amd64 	sha256:0ec55397e49a2ac76a34ae04f99cdfd26ec814fd1475fa2d821611be16294548	
schema  	0.11.0 	darwin/arm64 	sha256:7ef017fa6d123e7fa9805668fcea2d7baca2a61e1a6f08bb21a48ae57f055b96	
schema  	0.11.0 	linux/amd64  	sha256:f208a99e829c5bb1df1ae290438161a7bc3ce1d2caad949a8a9c09bfb2a496ac	
schema  	0.11.0 	linux/arm64  	sha256:602325d27b036abd74c166c857705a578338bf2d1eada81928ac3192e3a140ae	
schema  	0.11.0 	windows/amd64	sha256:9ae033656824163e82068393164a102b044d98a7567054cb448a6f05b56ce2ca	
schema  	0.11.0 	windows/arm64	sha256:87313c25de041f169f680cc9054f49f0a9209259ec8902446f3fcd622dc73dc8	
mirror  	0.8.0  	darwin/amd64 	sha256:52f028aa0d60a335219fe9b06f18288d2a082163ce0661af4d66d7133c7edbf0	
mirror  	0.8.0  	darwin/arm64 	sha256:4e4a974f6acaa15e808381d7fa19ca03ce2b0556675da99b51f51599d3839836	
mirror  	0.8.0  	linux/amd64  	sha256:4862e9c4a2c9ac6bfe4976766ec425b015f2e6730adebcf95184d1d94beb5b35	
mirror  	0.8.0  	linux/arm64  	sha256:71222a7bcfe0715da9481845b34b60df68034c1be386d59c3c3cef8c76fca6f3	
mirror  	0.8.0  	windows/amd64	sha256:cdd399ce097b4ae8f0a92f126d73672be7c9fb80c4728e960e966a26c981d2ff	
mirror  	0.8.0  	windows/arm64	sha256:c0339e7c64f56c348117fdd0d04d0b6ce5f618dabff1c1d35cde16a3fc058d03

• Added an optional [@version] field to flux plugin search [query]

./bin/flux plugin search operator@0.45.0
NAME    	VERSION	OS/ARCH      	DIGEST                                                                  
operator	0.45.0 	darwin/amd64 	sha256:8f8f6d04adb6a2451be1e5585753cf111536cf4a95b3f4716680d6b14f6bb667	
operator	0.45.0 	darwin/arm64 	sha256:cd85d5d84d2646a0bf991713fd2ee83e5c27a629094be447d4acd67fe5c54dea	
operator	0.45.0 	linux/amd64  	sha256:96198da9690965df56488a2a4a8b39cf56e2dc217a622446d5f00b1425f89fe8	
operator	0.45.0 	linux/arm64  	sha256:9c20eeca130f4a3374951dedfe12b89d7b093b521560f37f09bea39748a62142	
operator	0.45.0 	windows/amd64	sha256:9712026094a5c99efbbd8feabbf7bc30b737e9f93e0f534f14129b4ac1ed796b	
operator	0.45.0 	windows/arm64	sha256:9481a7a8d8111c8e9ff8de99bd10ef653aeeb7c2271e778b2c3e75c19b876f9a

Implementation Decisions

I would like to call out these decisions and invite feedback on the direction here!

Changed Columns

flux plugin search uses the columns NAME, DESCRIPTION, and INSTALLED. To pin by hash, we need at least two (additional) pieces of information: OS/ARCH and DIGEST.

Using all 5 columns would produce a very noisy console output. Instead, I opted to display only the "pinning relevant" columns when that code path is executed: NAME, VERSION, OS/ARCH, DIGEST.

Implied --digests

flux plugin search operator uses the standard output format.

flux plugin search operator --digests uses the "pinning relevant" output format.

flux plugin search name@1.2.3 implies --digests and therefore presents the "pinning relevant" information, since the user wants more information about a specific version.

Are we okay with this, or should we require the explicit use of --digests?

Potentially Large Output

For each new plugin added to the catalogue, flux plugin search --digests will produce 6 rows of output, more if we decide to support more architectures or operating systems.

I think this is fine, since --digests has to be set explicitly, and filtering down using the plugin name is possible.

Sequential Fetching

To display the SHA values, the manifest for each plugin has to be fetched. To keep the implementation simple, I opted for a simple loop instead of parallel fetching.

I think this is reasonable right now, but it might be slow if the number of plugins grows substantially.

fixes #6008

[matheuscscp]

Thanks very much for this PR @datosh!

codex/gpt-5.5 xhigh found a couple of nits:

• This command's main output is the table, and with --digests it starts doing network calls, hence why it makes sense to have the spinner. Codex suggested printing the spinner in stderr to separate the streams (table goes to stdout)
• We are ignoring the errors from plugin.ResolveVersion(manifest, version), and (this one I saw myself) we are failing the whole command on catalogClient.FetchManifest(entry.Name). I'm wondering if we shouldn't both capture all errors and print them all on stderr instead of failing the whole command. Then we can either skip the rows that failed or print a blank or indicative msg that it errored out.

[datosh]

Thanks for the feedback @matheuscscp

• This command's main output is the table, and with --digests it starts doing network calls, hence why it makes sense to have the spinner. Codex suggested printing the spinner in stderr to separate the streams (table goes to stdout)

plugin install has the same issue, so I opted to fix this in the shared spinner.New.

• We are ignoring the errors from plugin.ResolveVersion(manifest, version), and (this one I saw myself) we are failing the whole command on catalogClient.FetchManifest(entry.Name). I'm wondering if we shouldn't both capture all errors and print them all on stderr instead of failing the whole command. Then we can either skip the rows that failed or print a blank or indicative msg that it errored out.

Good catch! I have added code to record the errors and print them as warnings. Let me know if you agree with that approach!

[matheuscscp]

Thanks @datosh! One last nit: what happens if all digest lookups fail? Wondering if the command output will make sense in that case 🤔

[datosh]

Thanks @datosh! One last nit: what happens if all digest lookups fail? Wondering if the command output will make sense in that case 🤔

Since we have the len(rows) == 0 guard in place, it won't print the table, but of course, one line for each failed lookup. I would say this is acceptable behaviour. Would you prefer something else?

The exit code is 0, which might be reasonable to change if len(warnings) == len(plugins)...?

---

Do you agree with the other "implementation decisions" I laid out in the PR description?

[matheuscscp]

@datosh Yep, they make sense!

About the failure for all digests, looks like we enter if len(rows) == 0 and get one of:

• no query: No plugins found in catalog
• query present: No plugins matching "..." found in catalog

Which is a bit confusing, since there are plugins but we actually failed fetching digests for all of them...

[matheuscscp]

LGTM! 🚀

We can merge this either way, the comment above is quite a corner case 👍