如何为 Diffusers 🧨 做出贡献

我们 ❤️ 欢迎来自开源社区的贡献！ 每个人都受到欢迎，并且所有类型的参与——不仅仅是代码——都受到重视和赞赏。 回答问题、帮助他人、主动联系和改进文档对于社区来说都非常有价值，所以如果您愿意，请不要害怕参与进来！

我们鼓励每个人在我们的公共 Discord 频道中打招呼 👋。 我们讨论扩散模型的最新趋势，提出问题，展示个人项目，互相帮助贡献，或者只是闲逛 ☕。

无论您选择哪种方式贡献，我们都努力成为开放、热情和友善的社区的一部分。 请阅读我们的 行为准则，并在互动过程中注意遵守它。 我们还建议您熟悉指导我们项目的 伦理准则，并要求您遵守同样的透明和负责原则。

我们非常重视来自社区的反馈，因此如果您认为您有宝贵的反馈可以帮助改进该库，请不要害怕说出来 - 每条消息、评论、问题和拉取请求 (PR) 都会被阅读和考虑。

概述

您可以通过多种方式做出贡献，从回答问题和讨论到向核心库添加新的扩散模型。

在下文中，我们概述了不同的贡献方式，按难度升序排列。 所有这些对社区都很有价值。

• 1. 在 Diffusers 讨论论坛 或 Discord 上提问和回答问题。
• 2. 在 GitHub Issues 选项卡 上开启新 issue，或在 GitHub Discussions 选项卡 上开启新讨论。
• 3. 在 GitHub Issues 选项卡 上回答 issue，或在 GitHub Discussions 选项卡 上回答讨论。
• 4. 修复由 “Good first issue” 标签标记的简单 issue，请参阅 此处。
• 5. 为 文档 做出贡献。
• 6. 贡献一个 社区 Pipeline。
• 7. 为 示例 做出贡献。
• 8. 修复由 “Good second issue” 标签标记的更困难的 issue，请参阅 此处。
• 9. 添加新的 pipeline、模型或 scheduler，请参阅 “New Pipeline/Model” 和 “New scheduler” issues。 对于此贡献，请查看 设计理念。

如前所述，所有贡献对社区都有价值。 在下文中，我们将更详细地解释每种贡献。

对于所有贡献 4 - 9，您需要开启一个 PR。 在 开启拉取请求 中详细解释了如何操作。

1. 在 Diffusers 讨论论坛或 Diffusers Discord 上提问和回答问题

与 Diffusers 库相关的任何问题或评论都可以在 讨论论坛 或 Discord 上提出。 此类问题和评论包括（但不限于）

• 训练或推理实验的报告，旨在分享知识
• 个人项目的展示
• 关于非官方训练示例的问题
• 项目提案
• 一般反馈
• 论文摘要
• 在基于 Diffusers 库构建的个人项目上寻求帮助
• 一般问题
• 关于扩散模型的伦理问题
• ……

在论坛或 Discord 上提出的每个问题都积极鼓励社区公开分享知识，并且很可能在未来帮助有相同问题的初学者。 请提出您可能有的任何问题。 本着同样的精神，您通过回答这些问题对社区提供了巨大的帮助，因为这样您就可以为所有人公开记录知识以供学习。

请 记住，您在提出或回答问题上投入的精力越多，公开记录的知识质量就越高。 同样，良好提出和良好回答的问题会创建一个高质量的知识库，每个人都可以访问，而糟糕的问题或答案会降低公共知识库的整体质量。 简而言之，高质量的问题或答案是精确、简洁、相关、易于理解、可访问和格式良好/良好提出。 有关更多信息，请浏览 如何编写一个好的 issue 部分。

关于频道的注意事项： 论坛 更容易被 Google 等搜索引擎索引。 帖子按受欢迎程度而不是时间顺序排列。 因此，查找我们之前发布的问题和答案更容易。 此外，论坛中发布的问题和答案可以轻松链接。 相比之下，Discord 具有类似聊天的格式，可以进行快速来回交流。 虽然您很可能在 Discord 上更快获得问题的答案，但随着时间的推移，您的问题将不再可见。 此外，在 Discord 上查找一段时间前发布的信息要困难得多。 因此，我们强烈建议使用论坛进行高质量的问题和答案，以尝试为社区创建持久的知识。 如果 Discord 上的讨论得出非常有趣的答案和结论，我们建议在论坛上发布结果，以便未来的读者更容易获得信息。

2. 在 GitHub issues 选项卡上开启新 issue

感谢用户通知我们他们遇到的问题，🧨 Diffusers 库才能如此强大和可靠。 因此，感谢您报告 issue。

请记住，GitHub issues 仅用于与 Diffusers 库直接相关的技术问题、错误报告、功能请求或关于库设计的反馈。

简而言之，这意味着所有与 Diffusers 库的代码（包括文档）无关的内容都不应在 GitHub 上提问，而应在 论坛 或 Discord 上提问。

开启新 issue 时，请考虑以下准则:

• 确保您已搜索过您的问题是否已被提出（使用 Issues 下 GitHub 上的搜索栏）。
• 请永远不要在另一个（相关的）issue 上报告新 issue。 如果另一个 issue 高度相关，请仍然开启一个新的 issue 并链接到相关的 issue。
• 确保您的 issue 以英语书写。 如果您不擅长英语，请使用优秀的免费在线翻译服务之一，例如 DeepL，将您的母语翻译成英语。
• 检查更新到最新 Diffusers 版本是否可以解决您的问题。 在发布 issue 之前，请确保 python -c "import diffusers; print(diffusers.__version__)" 高于或匹配最新的 Diffusers 版本。
• 记住，您在开启新 issue 上投入的精力越多，您的答案质量就越高，Diffusers issues 的整体质量也越好。

新 issue 通常包括以下内容。

2.1. 可复现的最小错误报告

错误报告应始终具有可复现的代码片段，并尽可能精简明了。 更详细地说，这意味着

• 尽可能缩小 bug 范围，不要只是转储您的整个代码文件。
• 格式化您的代码。
• 不要包含除依赖于它们的 Diffusers 之外的任何外部库。
• 始终 提供有关您环境的所有必要信息； 为此，您可以在 shell 中运行： diffusers-cli env 并将显示的信息复制粘贴到 issue 中。
• 解释 issue。 如果读者不知道 issue 是什么以及为什么是 issue，（他/她）就无法解决它。
• 始终 确保读者可以尽可能轻松地复现您的 issue。 如果您的代码片段由于缺少库或未定义的变量而无法运行，则读者无法帮助您。 确保您的可复现代码片段尽可能精简，并且可以复制粘贴到简单的 Python shell 中。
• 如果为了复现您的 issue 需要模型和/或数据集，请确保读者可以访问该模型或数据集。 您始终可以将您的模型或数据集上传到 Hub 以使其易于下载。 尽量保持您的模型和数据集尽可能小，以使复现您的 issue 尽可能轻松。

有关更多信息，请浏览 如何编写一个好的 issue 部分。

您可以在 此处 开启错误报告。

2.2. 功能请求

世界一流的功能请求应解决以下几点

1. 动机先行

• 它是否与库的问题/挫败感有关？ 如果是，请解释原因。 提供演示问题的代码片段是最好的。
• 它是否与您项目需要的东西有关？ 我们很乐意听到！
• 它是否是您正在从事的工作，并认为可能对社区有益？ 太棒了！ 告诉我们它为您解决了什么问题。

2. 写一个完整的段落来描述该功能；
3. 提供一个代码片段，演示其未来的用法；
4. 如果这与论文有关，请附上链接；
5. 附上您认为可能有所帮助的任何其他信息（图纸、屏幕截图等）。

您可以在此处提交功能请求。

2.3 反馈

关于库设计的反馈，以及说明其优点或缺点，对于核心维护者构建用户友好的库非常有帮助。要了解当前设计理念背后的哲学，请查看此处。如果您认为某个设计选择不符合当前的设计理念，请解释原因以及应如何更改。如果某个设计选择过度遵循设计理念，从而限制了用例，请解释原因以及应如何更改。如果某个设计选择对您非常有用，也请留下注释，因为这对未来的设计决策非常有价值。

您可以在此处提交关于反馈的 issue。

2.4 技术问题

技术问题主要关于库中某些代码以特定方式编写的原因，或代码的特定部分的作用。请务必链接到有问题的代码，并详细说明代码的哪一部分难以理解。

您可以在此处提交关于技术问题的 issue。

2.5 提议添加新的模型、调度器或 pipeline

如果扩散模型社区发布了您希望在 Diffusers 库中看到的新模型、pipeline 或调度器，请提供以下信息

• 扩散 pipeline、模型或调度器的简短描述，以及指向论文或公开发布的链接。
• 指向其任何开源实现(s)的链接。
• 如果模型权重可用，则提供模型权重的链接。

如果您愿意自己贡献模型，请告知我们，以便我们更好地指导您。另外，如果您能找到组件（模型、调度器、pipeline 等）的原始作者的 GitHub 句柄，请不要忘记标记他们。

您可以在此处提交模型/pipeline/调度器请求。

3. 在 GitHub issues 选项卡上回答 issue

在 GitHub 上回答 issue 可能需要一些 Diffusers 的技术知识，但我们鼓励所有人尝试，即使您不能 100% 确定您的答案是正确的。为 issue 提供高质量答案的一些技巧

• 尽可能简洁和精炼。
• 保持主题相关。对 issue 的回答应只关注该 issue 本身。
• 提供代码、论文或其他来源的链接，以证明或支持您的观点。
• 用代码回答。如果一个简单的代码片段就是 issue 的答案，或者展示了如何解决 issue，请提供一个完全可重现的代码片段。

此外，许多 issue 往往只是跑题、与其他 issue 重复或不相关。如果您可以回答此类 issue，鼓励 issue 的作者更加精确，提供重复 issue 的链接或将他们重定向到论坛或 Discord，这对维护者非常有帮助。

如果您已验证已提交的 bug 报告是正确的，并且需要在源代码中进行更正，请查看以下部分。

对于以下所有贡献，您都需要打开一个 PR。在打开 pull request 部分中详细解释了如何操作。

4. 修复 “Good first issue”

Good first issues 标有 Good first issue 标签。通常，issue 已经解释了潜在的解决方案应该是什么样子，以便更容易修复。如果 issue 尚未关闭，并且您想尝试修复此 issue，您可以直接留言 “I would like to try this issue.”。通常有三种情况

• a.) issue 描述已经提出了修复方案。在这种情况下，如果解决方案对您来说有意义，您可以打开一个 PR 或草稿 PR 来修复它。
• b.) issue 描述没有提出修复方案。在这种情况下，您可以询问建议的修复方案可能是什么样子，Diffusers 团队的某个人应该很快回答。如果您对如何修复它有一个好主意，请随时直接打开一个 PR。
• c.) 已经有一个打开的 PR 来修复该 issue，但该 issue 尚未关闭。如果 PR 已经过时，您可以简单地打开一个新的 PR 并链接到过时的 PR。如果最初想要修复该 issue 的贡献者突然没有时间继续进行，PR 经常会变得过时。这在开源中经常发生，并且非常正常。在这种情况下，如果您重新尝试并利用现有 PR 的知识，社区将非常高兴。如果已经有一个 PR 并且它是活动的，您可以通过提供建议、审查 PR 甚至询问是否可以为 PR 做出贡献来帮助作者。

5. 贡献文档

一个好的库总是有好的文档！官方文档通常是库的新用户最先接触的点之一，因此，为文档做出贡献是非常有价值的贡献。

为库做贡献可以有多种形式

• 更正拼写或语法错误。
• 更正文档字符串的不正确格式。如果您看到官方文档显示怪异或链接断开，如果您花一些时间更正它，我们将非常高兴。
• 更正文档字符串输入或输出张量的形状或维度。
• 澄清难以理解或不正确的文档。
• 更新过时的代码示例。
• 将文档翻译成另一种语言。

在 Diffusers 官方文档页面上显示的任何内容都是官方文档的一部分，都可以在相应的文档源中进行更正和调整。

请查看此页面，了解如何在本地验证对文档所做的更改。

6. 贡献社区 pipeline

贡献社区 pipeline 是与社区分享您的创造力和工作成果的好方法。它让您可以基于 DiffusionPipeline 进行构建，以便任何人都可以通过设置 custom_pipeline 参数来加载和使用它。本节将引导您完成如何创建一个简单的 pipeline，其中 UNet 仅执行一次前向传递并调用调度器一次（“一步” pipeline）。

1. 为您的社区 pipeline 创建一个 one_step_unet.py 文件。此文件可以包含您想要使用的任何软件包，只要用户安装了它即可。确保您只有一个 pipeline 类继承自 DiffusionPipeline，以便从 Hub 加载模型权重和调度器配置。将 UNet 和调度器添加到 __init__ 函数中。

   您还应该添加 register_modules 函数，以确保您的 pipeline 及其组件可以使用 save_pretrained() 保存。

from diffusers import DiffusionPipeline
import torch

class UnetSchedulerOneForwardPipeline(DiffusionPipeline):
    def __init__(self, unet, scheduler):
        super().__init__()

        self.register_modules(unet=unet, scheduler=scheduler)

1. 在正向传递（我们建议定义为 __call__）中，您可以添加任何您想要的功能。对于“一步” pipeline，创建一个随机图像，并通过设置 timestep=1 来调用 UNet 和调度器一次。

  from diffusers import DiffusionPipeline
  import torch

  class UnetSchedulerOneForwardPipeline(DiffusionPipeline):
      def __init__(self, unet, scheduler):
          super().__init__()

          self.register_modules(unet=unet, scheduler=scheduler)

      def __call__(self):
          image = torch.randn(
              (1, self.unet.config.in_channels, self.unet.config.sample_size, self.unet.config.sample_size),
          )
          timestep = 1

          model_output = self.unet(image, timestep).sample
          scheduler_output = self.scheduler.step(model_output, timestep, image).prev_sample

          return scheduler_output

现在，您可以通过将 UNet 和调度器传递给 pipeline 来运行 pipeline，或者如果 pipeline 结构相同，则加载预训练权重。

from diffusers import DDPMScheduler, UNet2DModel

scheduler = DDPMScheduler()
unet = UNet2DModel()

pipeline = UnetSchedulerOneForwardPipeline(unet=unet, scheduler=scheduler)
output = pipeline()
# load pretrained weights
pipeline = UnetSchedulerOneForwardPipeline.from_pretrained("google/ddpm-cifar10-32", use_safetensors=True)
output = pipeline()

您可以将您的 pipeline 作为 GitHub 社区 pipeline 或 Hub 社区 pipeline 共享。

7. 贡献训练示例

Diffusers 示例是训练脚本的集合，位于 examples 中。

我们支持两种类型的训练示例

• 官方训练示例
• 研究训练示例

研究训练示例位于 examples/research_projects 中，而官方训练示例包括 examples 下的所有文件夹，除了 research_projects 和 community 文件夹。官方训练示例由 Diffusers 的核心维护者维护，而研究训练示例由社区维护。这与6. 贡献社区 pipeline 中针对官方 pipeline 与社区 pipeline 提出的原因相同：核心维护者无法维护扩散模型的所有可能训练方法。如果 Diffusers 核心维护者和社区认为某种训练范式过于实验性或不够流行，则相应的训练代码应放在 research_projects 文件夹中，并由作者维护。

官方训练和研究示例都包含一个目录，其中包含一个或多个训练脚本、一个 requirements.txt 文件和一个 README.md 文件。为了让用户使用训练示例，需要克隆仓库

git clone https://github.com/huggingface/diffusers

以及安装训练所需的所有其他依赖项

cd diffusers
pip install -r examples/<your-example-folder>/requirements.txt

因此，在添加示例时，requirements.txt 文件应定义您的训练示例所需的所有 pip 依赖项，以便在安装所有这些依赖项后，用户可以运行示例的训练脚本。例如，请参阅 DreamBooth requirements.txt 文件。

Diffusers 库的训练示例应遵循以下理念

• 运行示例所需的所有代码都应在一个 Python 文件中找到。
• 应该能够从命令行使用 python <your-example>.py --args 运行示例。
• 示例应保持简单，并作为关于如何使用 Diffusers 进行训练的示例。示例脚本的目的是不是创建最先进的扩散模型，而是重现已知的训练方案，而无需添加太多自定义逻辑。作为这一点的副产品，我们的示例也力求充当良好的教育材料。

要贡献一个示例，强烈建议查看现有的示例，例如 dreambooth，以了解它们应该是什么样子。我们强烈建议贡献者使用 Accelerate 库，因为它与 Diffusers 紧密集成。一旦示例脚本可以工作，请务必添加一个全面的 README.md，说明如何精确地使用该示例。此 README 应包括

• 一个关于如何运行示例脚本的示例命令，如此处所示。
• 指向一些训练结果（日志、模型等）的链接，显示用户可以期望的结果，如此处所示。
• 如果您添加非官方/研究训练示例，请不要忘记添加一句您正在维护此训练示例的语句，其中包含您的 git 句柄，如此处所示。

如果您正在为官方训练示例做出贡献，请务必在其文件夹中添加一个测试，例如 examples/dreambooth/test_dreambooth.py。对于非官方训练示例，这不是必需的。

8. 修复 “Good second issue”

Good second issues 标有 Good second issue 标签。Good second issues 通常比 Good first issues 更难解决。issue 描述通常对如何修复 issue 的指导较少，并且需要感兴趣的贡献者对库有相当的了解。如果您有兴趣处理 good second issue，请随时打开一个 PR 来修复它，并将 PR 链接到 issue。如果您看到已经为此 issue 打开了一个 PR，但没有合并，请查看以了解为什么它没有合并，并尝试打开一个改进的 PR。与 good first issues 相比，good second issues 通常更难合并，因此请不要犹豫向核心维护者寻求帮助。如果您的 PR 几乎完成，核心维护者也可以加入您的 PR 并提交，以便将其合并。

9. 添加 pipelines、模型、调度器

Pipelines、模型和调度器是 Diffusers 库最重要的组成部分。它们提供了对最先进的扩散技术的轻松访问，从而使社区能够构建强大的生成式 AI 应用程序。

通过添加新的模型、pipeline 或调度器，您可能会为依赖 Diffusers 的任何用户界面启用新的强大用例，这对整个生成式 AI 生态系统可能具有巨大的价值。

Diffusers 有一些关于这三个组件的开放功能请求 - 如果您还不确定要添加哪个特定组件，请随意浏览它们

• 模型或 pipeline
• 调度器

在添加这三个组件中的任何一个之前，强烈建议您阅读理念指南，以更好地理解这三个组件中任何一个的设计。请注意，我们无法合并与我们的设计理念严重偏离的模型、调度器或 pipeline 添加，因为它会导致 API 不一致。如果您从根本上不同意某个设计选择，请打开一个反馈 issue，以便可以讨论是否应在库中的所有位置更改某个设计模式/设计选择，以及我们是否应更新我们的设计理念。整个库的一致性对我们非常重要。

请务必在 PR 中添加指向原始代码库/论文的链接，理想情况下，还应直接在 PR 上 ping 原始作者，以便他们可以关注进度并可能帮助解决问题。

如果您不确定或在 PR 中遇到困难，请不要犹豫留言请求首次审查或帮助。

Copied from 机制

在添加任何 pipeline、模型或调度器代码时，一个独特而重要的功能是 # Copied from 机制。您将在整个 Diffusers 代码库中看到它，我们使用它的原因是保持代码库易于理解和维护。使用 # Copied from 机制标记代码会强制标记的代码与其复制的代码完全相同。这使得在您运行 make fix-copies 时，可以轻松更新和传播跨多个文件的更改。

例如，在下面的代码示例中，StableDiffusionPipelineOutput 是原始代码，而 AltDiffusionPipelineOutput 使用 # Copied from 机制来复制它。唯一的区别是将类前缀从 Stable 更改为 Alt。

# Copied from diffusers.pipelines.stable_diffusion.pipeline_output.StableDiffusionPipelineOutput with Stable->Alt
class AltDiffusionPipelineOutput(BaseOutput):
    """
    Output class for Alt Diffusion pipelines.

    Args:
        images (`List[PIL.Image.Image]` or `np.ndarray`)
            List of denoised PIL images of length `batch_size` or NumPy array of shape `(batch_size, height, width,
            num_channels)`.
        nsfw_content_detected (`List[bool]`)
            List indicating whether the corresponding generated image contains "not-safe-for-work" (nsfw) content or
            `None` if safety checking could not be performed.
    """

要了解更多信息，请阅读 ~Don’t~ Repeat Yourself* 博客文章的这一部分。

如何编写好的 issue

您的 issue 写得越好，它就越有可能被快速解决。

1. 确保您为您的 issue 使用了正确的模板。您可以选择Bug Report、Feature Request、Feedback about API Design、New model/pipeline/scheduler addition、Forum 或空白 issue。在打开新 issue 时，请务必选择正确的一个。
2. 保持精确：为您的 issue 提供合适的标题。尝试尽可能简单地描述您的 issue。您在提交 issue 时越精确，理解 issue 并可能解决它所需的时间就越少。确保只为一个 issue 打开一个 issue，而不是多个 issue。如果您发现了多个 issue，只需打开多个 issue。如果您的 issue 是一个 bug，请尽可能精确地说明是什么 bug - 您不应只写 “Diffusers 中出现错误”。
3. 可重现性：没有可重现的代码片段 == 没有解决方案。如果您遇到 bug，维护者必须能够重现它。确保您包含一个可以复制粘贴到 Python 解释器中以重现 issue 的代码片段。确保您的代码片段有效，即没有缺少导入或缺少图像链接等… 您的 issue 应包含错误消息和一个可以复制粘贴而无需任何更改以重现完全相同的错误消息的代码片段。如果您的 issue 使用本地模型权重或读者无法访问的本地数据，则该 issue 无法解决。如果您无法共享您的数据或模型，请尝试制作一个虚拟模型或虚拟数据。
4. 极简化：尽可能简洁，尽力帮助读者尽快理解 issue。删除所有与 issue 无关的代码/所有信息。如果您发现了一个 bug，请尝试创建您可以创建的最简单的代码示例来演示您的问题，不要在发现 bug 后立即将您的整个工作流程转储到 issue 中。例如，如果您训练模型并在训练期间的某个时刻遇到错误，您应该首先尝试了解训练代码的哪个部分负责该错误，并尝试用几行代码重现它。尝试使用虚拟数据而不是完整数据集。
5. 添加链接。如果您要引用某个命名、方法或模型，请务必提供链接，以便读者可以更好地理解您的意思。如果您要引用特定的 PR 或 issue，请务必将其链接到您的 issue。不要假设读者知道您在说什么。您添加到 issue 中的链接越多越好。
6. 格式化。确保通过将代码格式化为 Python 代码语法，并将错误消息格式化为普通代码语法来很好地格式化您的 issue。有关更多信息，请参阅 GitHub 官方格式化文档。
7. 请将您的问题视为一篇精美的百科全书的条目，而不是等待解决的工单。每个新增的问题都是对公开知识的贡献。通过添加一篇措辞得当的问题，您不仅可以帮助维护者更轻松地解决您的问题，还可以帮助整个社区更好地理解库的某个方面。

如何编写好的 PR

1. 像变色龙一样。理解现有的设计模式和语法，并确保您添加的代码能够无缝地融入到现有的代码库中。与现有设计模式或用户界面显著不同的 Pull Request 将不会被合并。
2. 专注于重点。一个 Pull Request 应该只解决一个问题。确保不要陷入“在添加它的同时顺便修复另一个问题”的陷阱。解决多个不相关问题的 Pull Request 更难以审查。
3. 如果有所帮助，请尝试添加代码片段，展示如何使用您添加的功能。
4. 您的 Pull Request 的标题应该是对其贡献的总结。
5. 如果您的 Pull Request 解决了某个 issue，请在 Pull Request 描述中提及 issue 编号，以确保它们被链接（并且查阅 issue 的人知道您正在处理它）；
6. 要表明正在进行中的工作，请在标题前加上 [WIP] 前缀。这些对于避免重复工作以及区分已准备好合并的 PR 很有用；
7. 尝试按照 如何编写好的 issue 中解释的方式 формулировать 和格式化您的文本。
8. 确保现有测试通过；
9. 添加高覆盖率的测试。没有高质量的测试 = 无法合并。

• 如果您正在添加新的 @slow 测试，请确保它们在使用 RUN_SLOW=1 python -m pytest tests/test_my_new_model.py 时通过。CircleCI 不运行慢速测试，但 GitHub Actions 每晚都会运行！

10. 所有公共方法都必须具有信息丰富的文档字符串，并且可以很好地与 markdown 协同工作。有关示例，请参阅 pipeline_latent_diffusion.py。
11. 由于存储库快速增长，因此务必确保不添加会显著增加存储库负担的文件。这包括图像、视频和其他非文本文件。我们更倾向于利用 hf.co 托管的 dataset，例如 hf-internal-testing 或 huggingface/documentation-images 来放置这些文件。如果是外部贡献，请随时将图像添加到您的 PR 中，并要求 Hugging Face 成员将您的图像迁移到此数据集。

如何打开 PR

在编写代码之前，我们强烈建议您搜索现有的 PR 或 issue，以确保没有人已经在做同样的事情。如果您不确定，最好先打开一个 issue 以获得一些反馈。

您需要具备基本的 git 技能才能为 🧨 Diffusers 做出贡献。git 不是最容易使用的工具，但它有最全面的手册。在 shell 中键入 git --help 并享受吧。如果您更喜欢书籍，Pro Git 是一本非常好的参考书。

按照以下步骤开始贡献（支持的 Python 版本）

1. 通过单击存储库页面上的“Fork”按钮，Fork 存储库。这会在您的 GitHub 用户帐户下创建代码副本。

2. 将您的 Fork 克隆到本地磁盘，并将基础存储库添加为远程仓库

   已复制

   $ git clone git@github.com:<your GitHub handle>/diffusers.git
   $ cd diffusers
   $ git remote add upstream https://github.com/huggingface/diffusers.git

3. 创建一个新分支来保存您的开发更改

   已复制

   $ git checkout -b a-descriptive-name-for-my-changes

不要在 main 分支上工作。

4. 通过在虚拟环境中运行以下命令来设置开发环境

   已复制

   $ pip install -e ".[dev]"

如果您已经克隆了 repo，您可能需要 git pull 以获取库中的最新更改。

5. 在您的分支上开发功能。

在您开发功能时，应确保测试套件通过。您应该像这样运行受您的更改影响的测试

$ pytest tests/<TEST_TO_RUN>.py

在运行测试之前，请确保您安装了测试所需的依赖项。您可以使用以下命令执行此操作

$ pip install -e ".[test]"

您也可以使用以下命令运行完整的测试套件，但这需要一台强大的机器才能在合理的时间内产生结果，因为 Diffusers 现在已经发展壮大了很多。以下是它的命令

$ make test

🧨 Diffusers 依赖 black 和 isort 来保持其源代码格式的一致性。在您进行更改后，应用自动样式更正和一次性无法自动完成的代码验证，使用

$ make style

🧨 Diffusers 还使用 ruff 和一些自定义脚本来检查编码错误。质量控制在 CI 中运行，但是，您也可以使用以下命令运行相同的检查

$ make quality

一旦您对您的更改感到满意，请使用 git add 添加更改的文件，并使用 git commit 进行提交以在本地记录您的更改

$ git add modified_file.py
$ git commit -m "A descriptive message about your changes."

定期将您的代码副本与原始存储库同步是一个好主意。这样您就可以快速处理更改

$ git pull upstream main

使用以下命令将更改推送到您的帐户

$ git push -u origin a-descriptive-name-for-my-changes

6. 一旦您满意，请转到 GitHub 上您的 Fork 的网页。单击“Pull request”以将您的更改发送给项目维护者进行审核。

7. 维护者要求您进行更改是正常的。核心贡献者也会遇到这种情况！为了让每个人都能看到 Pull Request 中的更改，请在您的本地分支中工作并将更改推送到您的 Fork。它们将自动出现在 Pull Request 中。

测试

包含广泛的测试套件，用于测试库的行为和一些示例。库测试可以在 tests 文件夹中找到。

我们喜欢 pytest 和 pytest-xdist，因为它更快。从存储库的根目录，以下是如何使用 pytest 运行库测试的方法

$ python -m pytest -n auto --dist=loadfile -s -v ./tests/

实际上，这就是 make test 的实现方式！

您可以指定较小的测试集，以便仅测试您正在开发的功能。

默认情况下，会跳过慢速测试。将 RUN_SLOW 环境变量设置为 yes 以运行它们。这将下载数 GB 的模型 — 请确保您有足够的磁盘空间和良好的互联网连接，或者足够的耐心！

$ RUN_SLOW=yes python -m pytest -n auto --dist=loadfile -s -v ./tests/

完全支持 unittest，以下是如何使用它运行测试的方法

$ python -m unittest discover -s tests -t . -v
$ python -m unittest discover -s examples -t examples -v

将 Fork 的 main 分支与上游 (HuggingFace) main 分支同步

为了避免 ping 上游存储库，这会向上游 PR 添加引用注释并向参与这些 PR 的开发人员发送不必要的通知，在同步 Fork 存储库的 main 分支时，请按照以下步骤操作

1. 如果可能，请避免使用分支和 Fork 存储库上的 PR 与上游同步。而是直接合并到 Fork 的 main 分支中。
2. 如果绝对需要 PR，请在检出您的分支后使用以下步骤

$ git checkout -b your-branch-for-syncing
$ git pull --squash --no-commit upstream main
$ git commit -m '<your message without GitHub references>'
$ git push --set-upstream origin your-branch-for-syncing

风格指南

对于文档字符串，🧨 Diffusers 遵循 Google 风格。