Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Shipped example configs and docs should use unique plugin IDs

未关闭
#263 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
活跃
技术栈
markdown, python

调研方向

Start with EXAMPLE_PLUGINS in src/paperpi/example.py and the test that compares the generated example with paperpi.example.toml, then look at new_id in src/paperpi/web/plugins.py to see the existing ID form. The open questions about fixed versus random IDs and the config-check hint need a maintainer decision (txoof) before any edit. Done when the shipped example, docs and plugin READMEs use the agreed unique-ID form and tests cover it.

由索引模型根据 Issue 内容生成。

描述

area:core area:docs enhancement needs-decision

Found in the web interface demo (2026-10-10): the demo's xkcd plugin had id = "comic", so its storage folder was plugins/comic/. That config was written by hand on 2026-10-09 (after the id decision of 2026-10-08, M5 part 3a-0, #251), copying the style of what PaperPi ships.

Problem: only the Plugin Library makes unique IDs (<type>-<8 random hex>, e.g. xkcd_comic-3f9a1c2e). Everything we ship shows short, readable IDs, so people (and agents) copy that style:

  • paperpi.example.toml (made by src/paperpi/example.py, EXAMPLE_PLUGINS): clock, weather_berlin, weather_rio
  • README.md, docs/writing-plugins.md, docs/decisions/config-format.md: clock, weather_berlin, word_clock
  • every plugin README in src/paperpi/plugins/*/README.md: clock, xkcd, moon, system, ...

Readable IDs are easy to repeat (two people's configs, a plugin added twice, an ID reused after removing a plugin), and a reused ID shares a storage folder with whatever used it before.

Wanted: the defaults we ship get unique-enough IDs, in the same form the Library makes.

To decide (ask txoof):

  • The example config is made again by paperpi example-config and a test compares it with the copy in the repository, so its IDs must be fixed values (for example basic_clock-5c1e0a7b), not new random ones each time. Fixed values in the example are copied by everyone who uses it as it is, so they are unique between plugins in one file, not between installs. Is that enough? Or should paperpi example-config (and the installer, M6) write fresh random IDs into the file it makes for the user, and only the copy in the repository use fixed ones?
  • Docs and plugin READMEs: use the same <type>-<hex> form in every example, or keep short readable IDs there and say clearly that the web interface makes unique ones?
  • Should the config check give a hint for an ID that doesn't have the <type>-<hex> form (hand-written IDs stay allowed)?

Where: src/paperpi/example.py (EXAMPLE_PLUGINS), paperpi.example.toml, src/paperpi/web/plugins.py (new_id, to share one way of making IDs), the docs and plugin READMEs above, maybe src/paperpi/config.py (hint).

Done when: what we ship uses unique-enough IDs as decided, the docs explain where IDs come from, and tests cover it.

主要语言
Python
星标
205
派生
17
平均合并
6 小时 4 分钟
30 天内合并 PR
45

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

txoof/PaperPi 的其他 Issue

查看 txoof/PaperPi 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。