huggingface / huggingface/diffusers

Question about the `# Copied from` system

Open
#12,650 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

stale
Dominant language
Python
Stars
34.5k
Forks
7.3k
Avg merge
3d 3h
Merged PRs (30d)
91

Description

Hi team! 👋

While working on improving docstrings and type hints across scheduler files (issue #9567), I've noticed the # Copied from pattern used extensively throughout the codebase.

Examples:

  • Functions like betas_for_alpha_bar are duplicated across multiple schedulers
  • Output classes like DDPMSchedulerOutput are copied with name replacements (e.g., DDPM->EulerDiscrete)

My question: What's the rationale behind this duplication system instead of:

  1. Using a shared utils.py or common.py file for common functions
  2. Using class inheritance for similar Output classes

I understand there might be good architectural reasons (module independence, API stability, avoiding circular dependencies, etc.), but this isn't documented anywhere that I could find.

Suggested action: Regardless of the answer, I think we should either:

  • Option A: Refactor to use inheritance/shared utilities (if the current system is legacy)
  • Option B: Document this design decision in:
      - A CONTRIBUTING.md or architecture doc
      - Comments in the utils/check_copies.py script itself
      - Another README in the diffusers directory

This would help future contributors (like me! 😅) understand why this pattern exists and how to work with it properly when improving documentation. What do you think?

Thanks for maintaining such a great library! 🚀

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the scheduler examples named in the issue and utils/check_copies.py, then review the discussion for any decision about duplication, shared utilities, or inheritance. Done means the rationale and contributor workflow are documented in an agreed location such as CONTRIBUTING.md, an architecture document, or comments in the copy-checking script.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
developer-experience, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.