Skip to content

Conversation

BenjaminBossan
Copy link
Member

The reset_sessions function is removed but it's also no longer necessary to call it for the purpose we used it.

Moreover, the deprecated use_auth_token argument is fully removed now, so everywhere we used to pass it, it is now removed, unless a user passes it explicitly.

The reset_sessions function is removed but it's also no longer necessary
to call it for the purpose we used it.

Moreover, the deprecated use_auth_token argument is fully removed now,
so everywhere we used to pass it, it is now removed, unless a user
passes it explicitly.
@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@BenjaminBossan BenjaminBossan requested a review from Wauplin October 1, 2025 15:14
Copy link
Contributor

@Wauplin Wauplin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for handling this! I'm pre-approving as current code is correct but I'd recommend updating the use_auth_token logic.

"cache_dir": kwargs.get("cache_dir", None),
"token": kwargs.get("token", None),
}
if use_auth_token := kwargs.get("use_auth_token", None):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While is this correct, I would highly recommend to deprecate use_auth_token explicitly and forward it as token if passed. Something like this:

token = kwargs.get("token", None)
if use_auth_token := kwargs.get("use_auth_token", None) is not None:
    warnings.warn("`use_auth_token` is deprecated and will soon be removed. Use `token` instead.")
    token = use_auth_token

(warning message to adapt)

They both have the exact same behavior and use_auth_token has been deprecated for ~2 years in transformers (and will soon be removed anyway). So good if we can completely get rid of it in HF ecosystem mid-term.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also by doing so, no need for hf_kwargs which makes things more readable IMO

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So my reasoning for this is to explicitly not handle it for users. If they pass use_auth_token explicitly, they should have gotten the deprecation message for the last 2 years, as you mentioned. IIUC, should PEFT convert the argument to token, we would have a split in the HF libraries, with some still supporting use_auth_token and others not. Therefore, I thought that passing on the argument, even if it means it can cause an error if hfh 1.0 is installed, would be the preferred solution.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine for me 👍

@BenjaminBossan
Copy link
Member Author

@Wauplin I saw another issue, namely that we use local_dir_use_symlinks:

# Don't use symlink, because this prevents us from properly cleaning up the files once finished
local_dir_use_symlinks=False,

What is the solution here? Can the argument be safely removed if hfh 1.0 is being used?

@Wauplin
Copy link
Contributor

Wauplin commented Oct 2, 2025

Parameter local_dir_use_symlinks has been deprecated since quite some time now and is completely ignored even in 0.x version. So you can just remove it :)

@BenjaminBossan BenjaminBossan merged commit 24aebee into huggingface:main Oct 2, 2025
24 of 25 checks passed
@BenjaminBossan BenjaminBossan deleted the chore-compatibility-huggingface_hub-1.0 branch October 2, 2025 11:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants