Lazily build the default kernel mapping to decouple `kernels` from normal transformers usage
Author: jiqing-feng
Pull request: yes

## Problem

Importing `transformers.pipeline` fails when an incompatible `kernels` version is installed:

```python
from transformers import pipeline
```

```
File ".../kernels/layer/layer.py", line 76, in __init__
    raise ValueError("Either a revision or a version must be specified.")
ValueError: Either a revision or a version must be specified.
```

This happens even though the user never opts into kernels.

## Root cause

`integrations/hub_kernels.py` builds the default `_KERNEL_MAPPING` dictionary as a **module-level literal**, so every `LayerRepository(...)` / `FuncRepository(...)` is instantiated eagerly at import time.

Because transformers uses lazy submodule loading, `import transformers` alone does not touch this module. But `from transformers import pipeline` forces the chain
`pipelines → image_processing_utils → processing_utils → type_validators → activations → hub_kernels`,
which eagerly constructs the mapping and trips `kernels`' new "version or revision required" validation.

The mapping is only ever consumed by `register_kernel_mapping_transformers()`, which is called exclusively when the user sets `use_kernels=True`. Building it at import time effectively couples the optional `kernels` library to all transformers usage.

## Fix

Build the default kernel mapping **lazily**:

- `_build_kernel_mapping()` constructs the repositories (unchanged content) only when invoked.
- `get_kernel_mapping_transformers()` builds the mapping on first use and caches it.
- `register_kernel_mapping_transformers()` now calls `get_kernel_mapping_transformers()` instead of referencing a pre-built global.

No mapping entries, behavior, or public APIs change.

## Result

- `import transformers` ✅
- `from transformers import pipeline` ✅ (no `LayerRepository` is instantiated)
- The kernel mapping is constructed only when the user explicitly enables `use_kernels=True`.

This decouples `kernels` from normal transformers usage: users who don't use kernels are no longer affected by kernels-version incompatibilities at import time.


Comments:
The failing checks are **unrelated to this change**.

Hmmn, not sure about this! If the user has kernels installed, we assume that they want kernels. What scenario are you imagining where the user has installed a version of `kernels` ahead of the one that's installed with `transformers`, but also they don't want `kernels`?

> Hmmn, not sure about this! If the user has kernels installed, we assume that they want kernels. What scenario are you imagining where the user has installed a version of `kernels` ahead of the one that's installed with `transformers`, but also they don't want `kernels`?

The problem isn't "kernels installed but unwanted" — even users who *want* kernels are broken, because the failure is **unconditional and at import time**.

The default mapping is a module-level literal, so every `LayerRepository`/`FuncRepository` is built the moment `hub_kernels` is imported (which `from transformers import pipeline` triggers). So anyone running a model that never touches these kernels still crashes on plain `import pipeline`, despite never reaching the `use_kernels=True` path that actually uses the mapping. (And `kernels` is often pulled in transitively, not opted into.)

This PR doesn't disable or hide kernels — it just builds the default mapping **lazily**, on first use (i.e. under `use_kernels=True`). Kernels users get identical behavior; everyone else just isn't broken at import by an unrelated kernels-version mismatch.

Even with kernels installed, many workflows never actually use it. My goal is simply to make sure those cases don't break on a kernels version mismatch — improving fault tolerance, without changing anything for users who do rely on kernels.


View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46681&sha=59673b

Valid, but will merge the sync PR first and then we can revisit this, wdyt? We should get it merged this week

Meaning #46039

Just merged the PR, feel free to sync + update and then ping me :hugs: 

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46681)

Hi @vasqu . I have rebased the PR, and the failed tests are not related to my changes. Please review it. Thanks!

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46681). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.