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

Remove pluggy: it is only used as an entry-point loader, and the class-based hookspecs break on pluggy 1.7

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

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
1-2 天
新手友好度
63/100
Issue 类型
重构
描述清晰度
描述清楚
活跃度
活跃
技术栈
python
领域
tooling

调研方向

Start by tracing plugincode’s current entry-point loading and dependency declaration, then check how src/scancode/cli.py consumes the loaded plugin classes. Run the existing plugin-loading tests before and after the change; done means plugins load through importlib.metadata, duplicate names keep the first entry, subclass validation remains, and the marker decorators stay importable.

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

描述

Written by Claude Opus 5.5 via Claude Code for the plugincode and scancode-toolkit maintainers; I prompted it, it did the work, I read it.

This is filed by Ronny Pfannschmidt, a pluggy maintainer. The behaviour plugincode relies on was never part of pluggy's API, and pluggy will not restore it.

pluggy 1.7.0 breaks every plugincode stage at import time (aboutcode-org/scancode-toolkit#5363):

File ".../plugincode/__init__.py", line 182, in __init__
    self.manager.add_hookspecs(sys.modules[module_qname])
ValueError: did not find any 'pre_scan' hooks in <module 'plugincode.pre_scan' ...>

scancode-toolkit now caps pluggy < 1.7.0 (aboutcode-org/scancode-toolkit@1891da6acf). A cap is not a fix. The underlying problem is that plugincode does not use pluggy as a hook system at all.

What plugincode actually does with pluggy

  • @pre_scan_spec, @scan_spec, etc. decorate classes. Hookspecs are functions. On pluggy ≤ 1.6, add_hookspecs happened to accept these classes and created hooks named after them (PreScanPlugin, …) that nothing ever calls. pluggy 1.7 only accepts functions and methods, finds none, and raises.
  • @pre_scan_impl, @scan_impl, etc. also decorate classes. register() looks for marked attributes on the plugin object and finds none, so every plugin registers with zero hook implementations, on 1.6 and 1.7 alike.
  • No pm.hook.<name>(...) call exists in plugincode or scancode-toolkit.
  • What is left is load_setuptools_entrypoints(group) followed by list_name_plugin(). In other words: iterate importlib.metadata entry points, ep.load(), store {ep.name: cls}. scancode-toolkit then instantiates the classes and calls their methods directly (src/scancode/cli.py, around line 741).

A standalone script on pluggy 1.6.0 and 1.7.0 shows the above: the class-decorated "hookspecs" fail on 1.7, and register() of a class succeeds with no hook implementations on both versions.

Request

Drop the pluggy dependency and load plugins with importlib.metadata.entry_points(group=entrypoint) directly:

  • Keep ep.name as the plugin name. The first name wins and later duplicates are skipped, matching load_setuptools_entrypoints.
  • Keep the existing issubclass(plugin_class, plugin_base_class) validation.
  • Keep HookspecMarker / HookimplMarker exported as no-op decorators, so third-party plugins that apply @pre_scan_impl keep importing. They can be deprecated later.

This removes a dependency and keeps the plugin API unchanged for plugin authors. Once it is released, scancode-toolkit can drop the < 1.7.0 cap (tracked in aboutcode-org/scancode-toolkit, issue to follow).

主要语言
Python
星标
1
派生
2
PR 合并指标
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

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

aboutcode-org/plugincode 的其他 Issue

查看 aboutcode-org/plugincode 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

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