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