feat: don't show descriptions from non verbose search output

[esadek]

Remove driver descriptions from the dbc search (non verbose) output.

[amoeba]

Looks good, thanks. I'll let @zeroshade have a look before merging.

[ianmcook]

I think ideally we'd have the dbc search output show both the short name and the full name, like:

bigquery - Google BigQuery
duckdb - DuckDB
flightsql - Apache Arrow Flight SQL
mssql - Microsoft SQL Server
mysql - MySQL
postgresql - PostgreSQL
redshift - Amazon Redshift
snowflake - Snowflake
sqlite - SQLite
trino - Trino

Is something like that possible given the data we have available in the driver index?

[amoeba]

I'm with you in the sense that I think we almost certainly want to display more info than what's proposed by this PR. Adding vendor strings like in your example isn't possible right this second but it's not too hard.

My understanding is that the motivation for this change was to address @esadek's reaction to the current output,

$ dbc search
• bigquery - An ADBC driver for Google BigQuery developed by the ADBC Driver Foundry
• duckdb - An ADBC driver for DuckDB developed by the DuckDB Foundation
• flightsql - An ADBC driver for Apache Arrow Flight SQL developed under the Apache Software Foundation
• mssql - An ADBC driver for Microsoft SQL Server developed by Columnar
• mysql - An ADBC Driver for MySQL developed by the ADBC Driver Foundry
• postgresql - An ADBC driver for PostgreSQL developed under the Apache Software Foundation
• redshift - An ADBC driver for Amazon Redshift developed by Columnar
• snowflake - An ADBC driver for Snowflake developed under the Apache Software Foundation
• sqlite - An ADBC driver for SQLite developed under the Apache Software Foundation
• trino - An ADBC Driver for Trino developed by the ADBC Driver Foundry

I won't speak for @esadek but, after taking some time away from it, I now notice the text isn't super scannable and "An ADBC driver for" is very redundant. I like that the descriptions are regular though which is how we got to the above output in the first place.

We have at least two options to change this:

1. Update the description field in the drivers themselves (some drivers have their manifests built dynamically so, for those, the change is in the CDN deployment code not in the driver itself)
2. Do something just for the CDN index

I think (2) is better than (1) because a verbose description is fine for each driver and the issue is how it presents when you show a big list of them. i.e., what dbc needs is not necessarily what a driver author needs.

[esadek]

Regarding showing both short and full names, this still feels redundant to me. Most of the results would just be duplicates such as:

• duckdb - DuckDB
• mysql - MySQL
• postgresql - PostgreSQL
• snowflake - Snowflake
• sqlite - SQLite
• trino - Trino

In cases where it would not be just duplicate names, I think the short name is still sufficient.
If a user is looking to connect via Arrow Flight SQL, I think it's obvious that flightsql is the appropriate driver. Similarly, if a user is looking to connect to Microsoft SQL Server, mssql is probably good enough. If not, they can just run dbc search -v or quickly Google "mssql".

What do you guys think?

[esadek]

If we do want to include the full name, maybe we append "driver"?

• mssql - Microsoft SQL Server driver
• postgresql - PostgreSQL driver

[ianmcook]

@esadek I think you're correct right now that the short name is probably sufficient for most people to deduce what the database/engine/platform is, but as we add more over time, the short names will become increasingly unfamiliar and cryptic.

I like the idea to add a field containing the full name in the driver index YAML, and then use that here, potentially with driver or ADBC driver appended/prepended. @amoeba previous advocated for the YAML to have structured fields like this instead of a generic full description.

[ianmcook]

We can also play with colors here to make the output appear less duplicative at a glance.

[amoeba]

I think we're uncovering that our driver descriptions are themselves not information rich which is how we end up here. When we (soon) have two BigQuery drivers, what will we say about to help users pick between them?

To focus purely on the visual side, how much would tab-stop aligning help? I noticed cargo does that. Our output could look like,

$ dbc search
bigquery		# Driver for Google BigQuery developed by the ADBC Driver Foundry
duckdb			# Driver for DuckDB developed by the DuckDB Foundation
flightsql		# Driver for Apache Arrow Flight SQL developed under the Apache Software Foundation
mssql			# Driver for Microsoft SQL Server developed by Columnar
mysql			# Driver for MySQL developed by the ADBC Driver Foundry
postgresql		# Driver for PostgreSQL developed under the Apache Software Foundation
redshift   		# Driver for Amazon Redshift developed by Columnar
snowflake		# Driver for Snowflake developed under the Apache Software Foundation
sqlite			# Driver for SQLite developed under the Apache Software Foundation
trino			# Driver for Trino developed by the ADBC Driver Foundry

and we could also use colors for "Apache Software Foundation" and "ADBC Driver Foundry". Note I also removed "ADBC".

[zeroshade]

looks good to me!