RFC tokens should be persisted only with explicit request of the user

[adrinjalali]

When working with HfApi (or other parts of this library), as a user I expect setting the access token (via set_access_token or deprecated login) to set the token for the instance and not the user.

An example of why this becomes an issue was touched here: #787 (comment) where we noticed running tests locally overrides the persisted token of the user.

As a user, I would expect this to work:

api1 = HfApi().set_access_token(token1)
api1.create_repo(repo_id='my_repo1')  # not passing token here

api2 = HfApi().set_access_token(token2)
api2.create_repo(repo_id='my_repo2')  # not passing token here

api1.delete_repo(repo_id='my_repo1')  # again not passing token

Right now the second HfApi.set_access_token changes the default token of the user and that means api1.delete_repo would try to use the wrong token.

I suggest we deprecate persisting tokens by default, and have other methods or an argument to the method to explicitly indicate that it should be persisted.

cc @LysandreJik @julien-c @osanseviero

[adrinjalali]

An alternative API design which seems cleaner to me would be:

api1 = HfApi(token=token1)
api1.create_repo(repo_id='my_repo1')  # not passing token here

api2 = HfApi(token=token2)
api2.create_repo(repo_id='my_repo2')  # not passing token here

api1.delete_repo(repo_id='my_repo1')  # again not passing token

All methods would use the token from the instance, and if not provided, it'll try to fetch from the persisted one. If the user wants to persist a token, they can call a method which explicitly is there to persist the token (we can then talk about how we can persist the tokens not to temper with git).

[LysandreJik]

I like both! Having set_access_token being called in the HfApi constructor if a token is passed sounds sensible to me. Persisting the token in the instance also sounds like an API improvement to me.

[Wauplin]

Addressed and closed by #1116.