Hi 👋, thank you for opening this pull request! The pull request is converted to draft by default. The CI will be paused while the PR is in draft mode. When it is ready for review, please click the Ready for review button (at the bottom of the PR page). This will assign reviewers and trigger CI.

@cyyever I confirm, locally installing this branch fixes the issue #37339 👍

@cyyever if we remove the dynamic conditions for type checking, will this cause exceptions when those dependencies aren't present?

@cyyever if we remove the dynamic conditions for type checking, will this cause exceptions when those dependencies aren't present?

There are wrapped in type_checking and used by linter, so that only linters would complain if there are missing symbols.

@ArthurZucker what's the status here? I get the errors after the PR you mentioned landed as well.

@ArthurZucker The CI failures are unrelated.

sorry everyone I am not sure I understand what is the issue here / setup to reproduce?

Happy to merge if this is compatible with the recent init refactoring!

The rebase is quite recent

@ArthurZucker just rebased it.

@ydshieh have a look?

@cyyever Got to say I am less familiar on this aspect 😅 . I see you answered

There are wrapped in type_checking and used by linter, so that only linters would complain if there are missing symbols.

to @Rocketknight1 question

@cyyever if we remove the dynamic conditions for type checking, will this cause exceptions when those dependencies aren't present?

But I don't understand well:

• In Mypy errors since v4.51.0 #37339, do they have all the dependencies but yet still get the dummy objects (due to linter isn't smart enough?)
• Linters aren't smart enough to evaluate the conditions.: Is this mypy specific or any type checkers?
• I don't think we want to have exceptions when linters would complain if there are missing symbols.. I see you mentioned __all__. But in the meantime, do we have a way to avoid this? In other words, there is no way for linters to evaluate the conditions correctly ..?

Overall, I am open to merge, but we should resolve the case @Rocketknight1 mentioned at some point in the near future.

if we remove the dynamic conditions for type checking, will this cause exceptions when those dependencies aren't present?
No, because the import are wrapped inside TYPE_CHECKING, according to the doc:

 typing.TYPE_CHECKING

    A special constant that is assumed to be True by 3rd party static type checkers. It is False at runtime.

In
https://github.com/huggingface/transformers/issues/37339, do they have all the dependencies but yet still get the dummy objects (due to linter isn't smart enough?)
Linters aren't smart enough to evaluate the conditions.: Is this mypy specific or any type checkers?

Linters have to evaluate XXX_is_available in the old code and then catch an exception to deal with dummy objects or import the normal symbols, but I don't think most linters would be coded do that. At least mypy would fail, but I haven't check others.

I don't think we want to have exceptions when linters would complain if there are missing symbols.. I see you mentioned __all__. But in the meantime, do we have a way to avoid this? In other words, there is no way for linters to evaluate the conditions correctly ..?

It depends on what linters are allowed to do, and I don't consider dynamic evaluation is generally supported.

Is it possible to merge it? Because I have to recheck the changes in case init.py has more changes.

Could we have some progress on this work because users are complaining about mypy...

cc @ArthurZucker @Cyrilvallez the init refactor is done, I think this is ready for final review/approval!

Can you check if the failing test is related or not?

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.

@ArthurZucker It is a test numerical error, not an import error, so it is unrelated.

@ArthurZucker No failure

Merging!

Thanks 🤗