RFC: Pin all dependencies, new package `scancode-toolkit-lib` for use as a library
维护者通常 3 天内回复
@AyanSinhaMahapatra 已经在做这个了。
开始于 2026年10月19日。
评估
这个 Issue 还没有评估数据。
描述
Originally suggested by @tdruez in context of use of scancode-toolkit in scancode.io as a library, and as discussed with @pombredanne and other aboutcode maintainers:
We should consider pinning all dependencies in scancode-toolkit, as this fixes a few issues faced by us currently:
-
pip install scancode-toolkitbreaking more often because of a change in scancode dependencies, and often this takes a while to fix and release, requiring additional steps from scancode users installing scancode via pip. -
With
pip installwe are fetching the latest and greatest from pip for our libraries and this isn't the best thing with supply chain attacks and security issues being more common. -
Unexpected behaviour changes from updated dependencies which are harder to catch (as we only run a fraction of cor tests on latest from pip) and these can cause performance, quality issues which are hard to detect and fix.
So as a solution, we should:
- Pin all dependencies in
scancode-toolkit - Start releasing a new library
scancode-toolkit-libwhich has flexible dependency ranges (as we have in the current scancode-toolkit library) - Also adopt the newer
pylock.tomllockfile format - Development installation should still use latest from pip dependencies as a way to catch these issues early, potentially with the new feature in pip 26.0+
--uploaded-prior-to=https://pip.pypa.io/en/latest/user_guide/#filtering-by-upload-time
The reason behind having the default scancode-toolkit having pinned versions, as opposed to the new scancode-toolkit-lib, is having secure defaults, where we are installing a more secure set of dependencies usually with the default and presently used scancode-toolkit library, even at the added cost of slight friction of downstream tools updating their dependency to scancode-toolkit-lib.
Suggestions are welcome on the above and on better possible names for the new library (currently meantioned as: scancode-toolkit-lib)
- 主要语言
- Python
- 星标
- 2.7k
- 派生
- 831
- 平均合并
- 3 天 4 小时
- 30 天内合并 PR
- 7
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
aboutcode-org/scancode-toolkit 的其他 Issue
-
bug: Unreachable JSON extension and format validation in validate_input_path可能已有人在做 @0Cymantek0 于 19 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
aboutcode-org/scancode-toolkit#5351 · 1 条评论 ·
维护者通常 3 天内回复
-
CycloneDX output: metadata.properties[].value emits JSON array instead of string可能已有人在做 @0Cymantek0 于 19 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 62/100
aboutcode-org/scancode-toolkit#5349 · 1 条评论 ·
维护者通常 3 天内回复
-
Duplicate 'COPYLEFT' entries in legal file classification names in legal.py and classify.py可能已有人在做 @Pradeepbeleri 于 46 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
aboutcode-org/scancode-toolkit#5319 · 2 条评论 ·
维护者通常 3 天内回复
-
Duplicate autogen.sh entry in commoncode default ignores可能已有人在做 @Daksha1611 于 49 天前认领。 未关闭
难度 1/5 1 小时以内 新手友好度 92/100
aboutcode-org/scancode-toolkit#5316 ·
维护者通常 3 天内回复
-
Duplicate LGPL key in rubygems LICENSES_MAPPING makes one mapping unreachable可能已有人在做 @Daksha1611 于 49 天前认领。 未关闭
难度 1/5 1 小时以内 新手友好度 88/100
aboutcode-org/scancode-toolkit#5314 · 1 条评论 ·
维护者通常 3 天内回复
查看 aboutcode-org/scancode-toolkit 的全部 Issue
相似的 Issue
-
ai_p2 bug comp-datalake
难度 2/5 1-3 小时 新手友好度 85/100
ClickHouse/ClickHouse#128306 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
[bug] openlit: LLM spans from openlit 1.37+ get no OpenInference attributes, and cache and reasoning token counts are dropped可能已有人在做 @sohom-cs 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 74/100
Arize-ai/openinference#4199 · 1 个 reaction ·
维护者通常 2 天内回复
-
难度 1/5 1 小时以内 新手友好度 82/100
MichaelYcJo/SpecSeal#1192 ·