search

infinyon / fluvio

Lean and mean distributed stream processing system written in rust and web assembly. Alternative to Kafka + Flink in one.
https://www.fluvio.io/
Apache License 2.0
3.77k stars 505 forks source link

Hub: Connector download need better error message if arch is not present #3411

Open sehz opened 1 year ago

sehz commented 1 year ago

Error message when connector arch is not present: fluvio hub connector download infinyon/duckdb-sink@0.1.0 Using hub https://hub.infinyon.cloud downloading infinyon/duckdb-sink@0.1.0 to infinyon-duckdb-sink-0.1.0.ipkg Hub error: downloading infinyon/duckdb-sink@0.1.0 failed Server: Downloading package Status(404

This should be something like:

Connector infinyon/duckdb-sink@0.1.0 is not available for target `aarch64-unknown-linux-musl`. 
 However following targets are available:
     - X86-64-unknown-linux-musl.
solidiquis commented 11 months ago

So the server response for this one doesn't provide enough granularity to distinguish between say a misnamed package vs. a package that doesn't support a particular platform. Example:

$ fluvio hub connector download infinyon/duckdb-sink@0.1.0asasdfasdf

and

$ fluvio hub connector download --target i686-pc-windows-gnu infinyon/duckdb-sink@0.1.0

So simply returning available targets might mislead folks when the error is a simple misspelling.

I see a few ways to go about this:

  1. Make the error status from the server be a bit more granular, as in, distinguish between an unsupported platform vs. an actual 404 (say a misspelling) so that the CLI can provide the appropriate error message.
  2. Retrieve all available packages for various platforms first, cross check that with the target, then proceed or error. This of course costs an extra network call.
  3. Make a more general error message.

I don't believe that the codebase for the API is public so I wouldn't be able to do 1 without some help. If we go route 2, it would be of tremendous help if I could get some direction on how to query packages for a particular platform. If we go route 3, I'm open to suggestions on what the more general error message should be. I'm happy to provide a suggestion as well.

edit: Relevant piece of code

digikata commented 11 months ago

This is a solid assessment. Our package servers already have an index of all the packages already on the server side, so a hybrid of 1 and 2 would be to add a new endpoint (e.g. "connector/pkginfo") to return information about a particular package versions and supported arches.

github-actions[bot] commented 9 months ago

Stale issue message