Remove `use_auth_token` argument in favor of `token` everywhere

This topic is directly related to the discussion in https://github.com/huggingface/huggingface_hub/pull/928 and the change of strategy from https://github.com/huggingface/huggingface_hub/pull/1064.

For what I read in https://github.com/huggingface/huggingface_hub/pull/928, everyone agreed that it would be good to have a unique naming for the token (or use_auth_token) argument. The idea was to move everything to token to make things easy for devs. The case token=False would be semantically weird but still acceptable. All of this was before @julien-c highlighted the fact that use_auth_token was used a lot in downstream libraries and that changing it just for a naming problem not worth it.

The decision has been to say “all methods that require only a read access to the Hub would use use_auth_token while write actions will use token”. I still think that this rule is too implicit for devs that do not really know when to use use_auth_token or token without looking at the documentation. What do you think to move all write-action methods to use use_auth_token parameter ? If a user uses use_auth_token=False on a write-action it will fail straight away with an explicit message “hey, the token is required here” (+I doubt this will happen very often anyway).

On the downside, this means a deprecation cycle and to adapt downstream libraries to this naming. On the positive side, we will never have to discuss again about this token vs use_auth_token thingy + it will make life easier for anyone using hfh as a single parameter name will be used everywhere.

WDYT ? (ping @julien-c @LysandreJik @osanseviero @adrinjalali @lhoestq @SBrandeis who were opinionated on this subject)

(I feel that I’m a bit reopening a closed topic but I still feel quite uneasy with the current rule -especially since we refactored how tokens are passed-. If you think it’s too unnecessary to talk about this again, just tell me and I’ll close it for good)

EDIT: changed the PR title to exactly the opposite. Let’s go for having token everywhere !

[julien-c]

I agree with moving to a single param name.

I think #1064 changed the situation quite a bit and I would be supportive of aligning everything to token= everywhere.

Maybe we can do a longer deprecation cycle than usual (e.g. 4-5 months) for use_auth_token i.e. first, transparently support both param names (for a few months) using a decorator, then doing our regular deprecation.

[adrinjalali]

I’m more worried about the huge number of changes that this would mean for downstream libraries.

We could leave things as is, and have a longer deprecation cycle for removing them? More like, if token is given to a method, it overwrites the one from self.