Question about the `# Copied from` system

[delmalih]

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! 🚀

[DN6]

Hi @delmalih Here's a bit of background about the #Copied From pattern inherited from transformers.
https://huggingface.co/blog/transformers-design-philosophy

We are actively working to refine this pattern, because it is very likely that it has been overused in certain places, and perhaps we can streamline some aspects of the library through inheritance and shared modules.

[delmalih]

Thanks @DN6 for the context!

Update: I just discovered that the # Copied from mechanism is actually already documented in docs/source/en/conceptual/contribution.md! 🎉

I noticed we have two very similar contribution files:

• CONTRIBUTING.md (root)
• docs/source/en/conceptual/contribution.md

They cover mostly the same content but can get out of sync. Would it make sense to make one a symlink to the other to avoid maintaining two versions? Or is there a reason they need to stay separate?

Regarding overuse identification:
I'm still happy to help audit the codebase to identify places where the pattern has been overused. I could create a follow-up issue listing candidates for refactoring, such as:

• Utility functions that are truly generic (like betas_for_alpha_bar) and unlikely to diverge
• Output dataclasses that are identical across multiple schedulers
• Helper functions that don't contain model-specific logic

Let me know if this would be useful! 🚀

[delmalih]

Hi @DN6 👋
Gentle bump on this! One concrete suggestion in the meantime: would it make sense to add a symlink from the root CONTRIBUTING.md to docs/source/en/conceptual/contribution.md? Currently the root file just points to the docs, and having a symlink would make the contribution guidelines more discoverable directly from the repo root (and on GitHub's "Contributing" tab).
Happy to open a quick PR for this if you think it's a good idea!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the contributing guidelines are likely to be ignored.

[stevhliu]

hi @delmalih, sorry i'm just seeing this now. thanks for all your prs on improving the scheduler docstrings! 😊

• syncing the contribution docs would be super nice indeed
• an audit of # Copied from usage would also be great

if you're interested, this article by the Transformers team is also a great read on moving away from the # Copied from statements :)

[delmalih]

Thanks for sharing the context and the article!

It's a pleasure to contribute to the schedulers cleanup. It is indeed a significant undertaking, so I am proceeding file by file to ensure everything remains stable.

regarding the next steps:

1. I will open a PR shortly to sync the contribution docs as suggested.
2. Once I have finished the current overhaul of the docstrings/type hints, I will tackle the refactoring of the # Copied from statements to align with the new modular approach.

[stevhliu]

thanks, that sounds great!

i don't think we're at the point of moving away from the # Copied from statements to a more modular approach yet, so i wouldn't necessarily start that without some more discussions cc @DN6 @sayakpaul

but an audit of the # Copied from statements would be a very valuable first step to get a better picture and help us improve this usage pattern :)

[sayakpaul]

Thanks for your interest!

but an audit of the # Copied from statements would be a very valuable first step to get a better picture and help us improve this usage pattern :)

This would definitely be the first step!

Utility functions that are truly generic (like betas_for_alpha_bar) and unlikely to diverge

Well that's the thing. It doesn't apply to all schedulers, and hence cannot be used in the scheduling base class. But maybe it can be made into a utility function that resides in src/diffusers/schedulers/utils.py and other schedulers inherit from it while still doing "Copied from ..." as needed?

Some aspects of modularity are also being worked on in #12820. Hope this helps.

[delmalih]

Thanks @stevhliu and @sayakpaul for the feedback and for merging the PR!

I fully understand the cautious approach regarding the modularity changes.

Regarding the next steps:

1. Docstrings first: I will prioritize finishing the current overhaul of docstrings and type hints to ensure that work is completed cleanly.
2. Audit: Once that is done, I will proceed with the audit as suggested. My plan is to establish a comprehensive list of all functions duplicated across the schedulers folder to provide a full overview and a dependency tree.

I'll also keep an eye on #12820 to stay aligned. Thanks again for the guidance!

[sayakpaul]

Thank you so much!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the contributing guidelines are likely to be ignored.