Studio token: make it global, make it easier to setup

[shcheklein]

Since token is being also used by VS Code we need to come up with a single way to manage it. I think it should be done in a way similar to gh app and not via DVC config per repo.

We have now a bit broken experience since we have it in two places and managed differently.

cc @mattseddon

[dberenbaum]

@shcheklein I added it to #9074.

Unless I'm mistaken, it's already possible to make it global via dvc config --global (see #9213), so I think this is just about making it easy to set that up via some command that would automatically write to that global config, right?

Somewhat related to #9217. If we have some command like dvc studio login that always writes to the global config, we don't need to worry too much about users writing it to their project config.

[shcheklein]

Unless I'm mistaken, it's already possible to make it global via dvc config --global (see #9213), so I think this is just about making it easy to set that up via some command that would automatically write to that global config, right?

Yep, it might be enough (btw, should we use user vs global - this names confuses me every time I use it).

[skshetry]

It is —global. I am -1 on adding a separate command for now. Let’s release what we have, and then come back to this. It’s too early to implement this at this time.

[shcheklein]

It is —global. I am -1 on adding a separate command for now.

You mean dvc studio login? We can't add it w/o a proper Studio support anyways. I think it worth mentioning that it's not about making it a syntax sugar for the dvc config it goes way beyond that.

[skshetry]

Yeah, let’s wait for feedback. dvc studio login and keyring support can be implemented when we get a good response to this.

[dberenbaum]

You mean dvc studio login? We can't add it w/o a proper Studio support anyways. I think it worth mentioning that it's not about making it a syntax sugar for the dvc config it goes way beyond that.

@shcheklein Can you expand? I didn't get what you mean, and I'd also like to here how else you see it being used.

Yeah, let’s wait for feedback. dvc studio login and keyring support can be implemented when we get a good response to this.

@skshetry I see your point and maybe it's not a blocker, but it seems harder to get a good response when we don't make it easy to setup.

Another hybrid approach would be to keep this kind of experience limited to VS Code for now, but have VS Code save it to the global DVC config.

[shcheklein]

@shcheklein Can you expand? I didn't get what you mean, and I'd also like to here how else you see it being used.

It has to reach out to Studio, open the browser, get the code back, save it to config. So, that's why it's not as simple as, let's say as dvc cache dir.

Does it answer the question, Dave?

Another hybrid approach would be to keep this kind of experience limited to VS Code for now, but have VS Code save it to the global DVC config.

My 2cs on this. It's easy to do on DVC and I don't see a single reason (considering the scope) of not doing that. But it would require Studio changes first - and that's where most of complexity is. VS Code itself won't help that much or improve the experience a lot.

[skshetry]

We don’t have to implement everything. This is just the first iteration.

This is an integration, so we have to take both Studio and DVC into account. There are still other higher priority issues in Studio to iron out. I’d prefer that experience to be smooth first.

Let’s release what we have, get feedback from users, and iterate. It’s not good if we keep on increasing scope.

[shcheklein]

We should keep in mind that this it top of the funnel, @skshetry - means that more users potentially can try the whole combination of DVC + Studio + VS Code. It's important to optimize. I would still go with this from the Studio side- if we have there capacity or not.

[skshetry]

@shcheklein, do you mind creating an issue on the Studio side, please?

[shcheklein]

It exists already https://github.com/iterative/studio/issues/5158

[skshetry]

Thanks. I am dropping priority to p2-medium Medium priority, should be done, but less important for now. We can reprioritize when it gets implemented in Studio.

[dberenbaum]

That's fair @skshetry, it doesn't make sense until we have Studio support. I see you quickly have been reprioritizing as needed, so are you open to it being a quick follow-up once that's implemented? I don't think we need to spend more time discussing if it's only about a few days or at most a week or two difference in time.

[skshetry]

It depends on what auth flow will be used. It probably also depends on if we are going to support custom Studio servers or not, etc.

[dberenbaum]

Some rough idea of how the CLI experience could look (copied from #9074 (comment)):

$ dvc studio login
Redirecting you to studio.iterative.ai...
Token saved to `~/.config/dvc/config`
Would you like to enable automatic experiment sharing? (Y/n)

I'm not sure I like enabling auto sharing by default, but I think it should at least be an option.

[omesser]

I'm not sure I like enabling auto sharing by default, but I think it should at least be an option.

👍 - I recommend we add a link to docs site to some page explaining exactly WHAT "automatic experiment sharing" means and the implication of turning this on, and if there aren't too harsh downsides, it might be ok to even leave this on as default. but if we're asking so explicitly it doesn't matter too much either way imo

[dberenbaum]

https://github.com/iterative/studio/issues/7652 is in progress. Once that is complete, dvc can add this.

Thoughts on the UI? Should we call it dvc login, dvc auth login, dvc studio login, something else?

[dberenbaum]

Looks like this is ready per https://github.com/iterative/studio/issues/5158

[amritghimire]

Will try to implement this and ask for review.