* Add `use_kernel_forward_from_hub` decorator
This decorator replaces a layer's `forward` with the `forward` of
a layer on the hub.
* Add support for registering a mapping for the duration of a context
This change makes `_KERNEL_MAPPING` a context variable and adds a
`use_kernel_mapping` context manager. This allows users to register
a mapping for the duration of a context.
* Update layer docs
* ruff fix
* Remove an old bit from the docs
* Extend layer mapping example
Co-authored-by: Arthur <48595927+ArthurZucker@users.noreply.github.com>
* Support stringly-typed device type
* Forward-reference `register_kernel_mapping` in monkeypatching section
* Use stringly-typed device name in layer mapping example
Co-authored-by: Arthur <48595927+ArthurZucker@users.noreply.github.com>
---------
Co-authored-by: Arthur <48595927+ArthurZucker@users.noreply.github.com>
* Remove old build backend
* Add types, use `Path` where possible
* Remove unused `get_metadata` function
This function is also problematic, because it assumes that `build.toml`
is always present.
* Support kernels that are not pre-compiled
This change add support for kernels that are not precompiled (such as
Triton-based kernels). For Torch, these kernels are assumed to be in
`build/torch-noarch`. Kernel download functions will filter on both
the expected (CUDA) build variant and the `noarch` variant. If a binary
variant exists, it is used. Otherwise the `noarch` variant is used
when present.
We don't append a Torch version, since in most cases the output for
every `ver` in `build/torch<ver>-noarch` would be the same. If some
kernel needs features that are only available in a specific Torch
version, the capabilities can be checked by the kernel itself at
runtime.
* CI: system Python does not have headers installed
This makes the lock file a fair bit shorter than per-file hashes. The
hash is computed from filenames + SHA-1 hash for git objects/SHA-256
hash for LFS files.
So far we have been using the extension name in `build.toml` as
the module name. However, this can cause naming conflicts. For
instance, if a kernel named `moe` is loaded through `hf_kernels`,
it would be registered as the `moe` module. This would cause
subsequent imports of a module named `moe` from the Python path
to be resolved as the module loaded through `hf_kernels`.
Solve this issue by adding some unique material to the module
name (hex-encoded hash of the kernel path).
* Only import torch when needed
This avoids the (costly) torch load when e.g. the setuptools hooks
are running in downstream packages.
* Lock Python/Torch versions
Also update to Torch 2.5.1/2.6.0.
* Set the minimum Python version to 3.9
* Change step description
* Accept version specifications for kernels in `pyproject.toml`
We lock the highest compatible version. Until we have a better
mechanism, tags of the form `vX.Y.Z` are recognized as versions.
The versions are locked by their git commit SHA.
* Fix Docker CI issue
* PoC: allow users to lock the kernel revisions
This change allows Python projects that use kernels to lock the
kernel revisions on a project-basis. For this to work, the user
only has to include `hf-kernels` as a build dependency. During
the build, a lock file is written to the package's pkg-info.
During runtime we can read it out and use the corresponding
revision. When the kernel is not locked, the revision that is provided
as an argument is used.
* Generate lock files with `hf-lock-kernels`, copy to egg
* Various improvements
* Name CLI `hf-kernels`, add `download` subcommand
* hf-kernels.lock
* Bump version to 0.1.1
* Use setuptools for testing the wheel
* Factor out tomllib module selection
* Pass through `local_files_only` in `get_metadata`
* Do not reuse implementation in `load_kernel`
* The tests install hf-kernels from PyPI, should be local
* docker: package is in subdirectory
