auth: highlight default profile and unify pickers across login/logout/switch/token#5218
Conversation
…/switch/token The interactive profile pickers shown by `databricks auth switch`, `databricks auth logout`, `databricks auth token`, and `databricks auth login` now mark the default profile with a "[default]" tag and move it to the top of the list. The pickers used by login/token are identical (with "Create a new profile" and "Enter a host URL manually" entries), and the pickers used by switch/logout share a common implementation. Co-authored-by: Isaac
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
…onfig - pickAuthProfile gains a SelectedNoun option so logout prints "Selected profile" and switch prints "Default profile" while token and login keep "Using profile". - auth login now shows the picker even when no profiles are configured, so a first-time user can pick web-based discovery (Create a new profile) or a manual host URL from the start. The label adapts to "How would you like to log in?" in the empty-config case. Co-authored-by: Isaac
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
| case profilePickerEnterHost: | ||
| host, err := promptForHost(ctx) | ||
| if err != nil { | ||
| return err | ||
| } | ||
| authArguments.Host = host |
There was a problem hiding this comment.
[Question] Do we want this to fall through to the profile name prompt bellow?
From playing around if I introduce the host of a workspace for which I already have a profile I get asked to input a profile name and it creates a new profile.
Is this what we want or should we have some discovery mechanism where we show the available profiles for that host?
There was a problem hiding this comment.
I think we want to keep it simple, and assume you want to create a new profile in this case
| if includeExtras { | ||
| items = append(items, | ||
| pickerItem{Name: profilePickerCreateNewLabel, IsExtra: true, Extra: profilePickerCreateNew}, | ||
| pickerItem{Name: profilePickerEnterHostLabel, IsExtra: true, Extra: profilePickerEnterHost}, | ||
| ) | ||
| } |
There was a problem hiding this comment.
[Question] From the point of view of the semantics of these commands it makes sense to have the extras at the bottom. You call login not a hypothetical create. However, if you actually want to create a profile you have to go though login and if you have multiple accounts you have to go through ALL of them and reach the bottom of the list.
Is this something we should acknowledge but accept or should we move the extra options at the top and then have the profiles bellow?
There was a problem hiding this comment.
The question is ultimately, do we think people are more likely to use databricks auth login to refresh tokens for existing profiles or to create new profiles. My assumption is that the more profiles you have, the less likely you are to want to create new profiles (and also the more advanced a user you would be). So thats why the behavior is how it is right now
| case profilePickerEnterHost: | ||
| // Fall through — setHostAndAccountId will prompt for the host. |
There was a problem hiding this comment.
Same question regarding entering host and creating new profiles
…ult-profile-picker # Conflicts: # NEXT_CHANGELOG.md
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
2 participants
Why
When users have several profiles in
~/.databrickscfg, the picker shown bydatabricks auth switch,databricks auth logout,databricks auth token, anddatabricks auth logindoesn't tell them which one is currently the default. Locating the default in a long list, especially when commands try to pre-fill it, is more guesswork than it should be. The four commands also drift in their picker implementations:auth tokenhas a richer picker that lets users create a new profile, whileauth loginonly has a text prompt for the profile name, andauth logoutandauth switchhave their own slightly different flavors.Changes
Before: Each auth command had its own picker. None highlighted the default profile.
auth logincouldn't pick an existing profile from a list.Now: The four auth commands share two picker shapes:
auth switchandauth logoutuse a profile-only pickerauth tokenandauth loginuse the same picker plus "Create a new profile" and "Enter a host URL manually" entriesIn all four, the default profile (from
[__settings__]/default_profile) is moved to the top of the list and tagged[default](green when highlighted).Implementation:
libs/databrickscfg/profile/select.go: added aDefaultfield toSelectConfig. When set,SelectProfilereorders so the default comes first and exposesIsDefaultto templates. Existing callers that pass custom templates are unaffected.cmd/auth/profile_picker.go(new):pickAuthProfileis the auth-package picker. It supports anIncludeExtrasoption for the "Create new" / "Enter host" entries used byauth loginandauth token.cmd/auth/switch.goandcmd/auth/logout.go: switched topickAuthProfilewith no extras andDefaultset.cmd/auth/token.go: replaced the bespoke picker (promptForProfileSelection,profileSelectItem,profileSelectionResult) withpickAuthProfile(IncludeExtras: true,Defaultset).cmd/auth/login.go: when the command is interactive and no--profile,--host, or positional argument is provided, show the same picker asauth token. Selecting an existing profile triggers a re-login (OAuth refresh) against that profile's host.Test plan
libs/databrickscfg/profile/select_test.goand for the picker incmd/auth/profile_picker_test.go.cmd/auth/...unit tests andacceptance/cmd/auth/...acceptance tests pass../task checks,./task fmt-q, and./task lint-qare clean.This pull request and its description were written by Isaac.