[zeroshade]

Add a DBC_USER_AGENT_SUFFIX environment variable that appends a custom string to the User-Agent header on requests made by the dbc CLI.

• New library option dbc.WithUserAgentSuffix(suffix): appends " " + suffix to the client's user agent after all options are applied, so it composes with WithUserAgent in any order.
• The CLI applies the suffix to registry/API requests (dbcClient), dbc auth login (authHTTPClient), and package downloads (dbc.DefaultClient used by PkgInfo.DownloadPackage).
• Not covered: auth-package calls that use Go's http.DefaultClient directly (OIDC discovery, token/API-key refresh, license fetch); those never carried dbc's User-Agent.

[ianmcook]

Since this is a fairly obscure feature that the vast majority of users don't need to know about, can we hide it from the help output?

[zeroshade]

If we hide it from the help output, how will the people who want it find it?

[ianmcook]

The mention in the site docs is enough to allow people to discover it. And I'm not so worried about discoverability because mostly this is a thing people will use because we ask them to. It's a purely developer-focused feature (not an end-user-focused feature) and I really hate to have it add more noise to the dbc UX for regular users and waste more of our users' agent tokens having it in the help.

[zeroshade]

Should I remove it from the autocomplete stuff as well?

[ianmcook]

Should I remove it from the autocomplete stuff as well?

I suppose. I'm less sure about that. @amoeba wdyt?

[amoeba]

I initially when we talked about this, thought we'd do it as an environment variable. The flag requires the user to set it in every invocation but, in theory, anyone who wants to customize their UA would want it customized in every call. So an env var is more ergonomic, I think. Plus, since above we're talking about having a flag that's hidden, why not just use an env var? And, as an aside, the current PR reads like it's allowing the user to override the entire UA.

The closest thing I could find to what we're doing here is pip's PIP_USER_AGENT_DATA. How about DBC_USER_AGENT_DATA?

• USER_AGENT_DATA="myapp" dbc search would give a UA string like "dbc-cli/1.2.3 (linux; amd64) myapp"
• CI=1 USER_AGENT_DATA="myapp" dbc search would give a UA string like "dbc-cli/1.2.3 (linux; amd64) CI myapp"

Since we're now up to two possible UA suffixes, we might want to come up with something more parse-able. pip uses a JSON string. We could do that or separate with semicolons.

[ianmcook]

The flag requires the user to set it in every invocation but, in theory, anyone who wants to customize their UA would want it customized in every call.

This only ever needs to be set when dbc is called programmatically; there is no user invoking it; it's just being invoked in code. So I don't think user inconvenience is really a factor here.

But if the general pattern for other tools is that this is set in an env var, then I agree with @amoeba that we should follow the principle of least astonishment and do it with an env var.

[amoeba]

If we go the env var route, it might be good to line the client config struct member name with the env var. As is, this would mean the env var is DBC_USER_AGENT_SUFFIX.

[zeroshade]

I'm fine with switching this to an env var instead of a flag if we think that's the better route

[amoeba]

I think we should go with an env var DBC_USER_AGENT_SUFFIX instead of a flag and a follow-up PR to add it to the new env var docs and other docs once 0.4.0 is out.

[zeroshade]

@ianmcook @amoeba Updated this to use the env var.

[amoeba]

Do we want to split out the completion updates into a separate PR? I'm not sure if they're related or what's going on there.

[zeroshade]

yea, they were something that was an update found when i was adding the flag to the completion scripts. i'll break them out to a separate PR