Copilot instructions

1# copilot-instructions.md Guide for Hugging Face Transformers
2 
3This copilot-instructions.md file provides guidance for code agents working with this codebase.
4 
5## Core Project Structure
6 
7- `/src/transformers`: This contains the core source code for the library
8  - `/models`: Code for individual models. Models inherit from base classes in the root `/src/transformers` directory.
9- `/tests`: This contains the core test classes for the library. These are usually inherited rather than directly run.
10  - `/models`: Tests for individual models. Model tests inherit from common tests in the root `/tests` directory.
11- `/docs`: This contains the documentation for the library, including guides, tutorials, and API references.
12 
13## Coding Conventions for Hugging Face Transformers
14 
15- PRs should be as brief as possible. Bugfix PRs in particular can often be only one or two lines long, and do not need large comments, docstrings or new functions in this case. Aim to minimize the size of the diff.
16- When writing tests, they should be added to an existing file. The only exception is for PRs to add a new model, when a new test directory should be created for that model.
17- Code style is enforced in the CI. You can install the style tools with `pip install -e .[quality]`. You can then run `make fixup` to apply style and consistency fixes to your code.
18 
19## Copying and inheritance
20 
21Many models in the codebase have similar code, but it is not shared by inheritance because we want each model file to be self-contained.
22We use two mechanisms to keep this code in sync:
23 
24- "Copied from" syntax. Functions or entire classes can have a comment at the top like this: `# Copied from transformers.models.llama.modeling_llama.rotate_half` or `# Copied from transformers.models.t5.modeling_t5.T5LayerNorm with T5->MT5`
25  These comments are actively checked by the style tools, and copies will automatically be updated when the base code is updated. If you need to update a copied function, you should
26  either update the base function and use `make fixup` to propagate the change to all copies, or simply remove the `# Copied from` comment if that is inappropriate.
27- "Modular" files. These files briefly define models by composing them using inheritance from other models. They are not meant to be used directly. Instead, the style tools
28  automatically generate a complete modeling file, like `modeling_bert.py`, from the modular file like `modular_bert.py`. If a model has a modular file, the modeling file
29  should never be edited directly! Instead, changes should be made in the modular file, and then you should run `make fixup` to update the modeling file automatically.
30 
31When adding new models, you should prefer `modular` style and inherit as many classes as possible from existing models.
32 
33## Testing
34 
35After making changes, you should usually run `make fixup` to ensure any copies and modular files are updated, and then test all affected models. This includes both
36the model you made the changes in and any other models that were updated by `make fixup`. Tests can be run with `pytest tests/models/[name]/test_modeling_[name].py`
37If your changes affect code in other classes like tokenizers or processors, you should run those tests instead, like `test_processing_[name].py` or `test_tokenization_[name].py`.
38 
39In order to run tests, you may need to install dependencies. You can do this with `pip install -e .[testing]`. You will probably also need to `pip install torch accelerate` if your environment does not already have them.
40