[Feature] 为模组管理增加一个依赖分析功能
Open
Nobody has claimed this yet.
enhancement
- Dominant language
- Java
- Stars
- 10.1k
- Forks
- 934
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 82
Description
描述 | Description
就是类似于apt那种,对文件夹里的模组在后台自动进行依赖分析。
可以通过一些方式把依赖关系显示出来,比如哪些依赖于A,哪些依赖于B,这种树状结构?
实现的话,至少fabric应该难度不大,模组的fabric.mod.json里面都写了的
"depends": {
"fabricloader": "\u003e\u003d0.15.0",
"fabric-api": "\u003e\u003d0.95.3",
"puzzleslib": "\u003e\u003d20.4.18",
"minecraft": "1.20.4",
"java": "\u003e\u003d17"
},
这个是EffectDescriptions的
原因 | Reason
就不说大型整合包,只算我自己平时用的Fabric的模组列表。
前期我还能够记得起来大致的依赖关系,后面数量一起来就完全搞不清楚谁是谁了。具体的例子的话,我至少能找两种:
- 比如今天模组更新之后崩溃,我看日志觉得可能和sodium有关系,我就给他禁用了进行测试,一启动游戏fabric loader直接报告三四个依赖于sodium的模组不能工作,我还要去挨个找到你是谁你是谁每个都关掉。
- 我之前用过Music Player,这家伙依赖于U Team Core,后来不用了,我就把Music Player给禁用了。U Team Core被我忘在一边了,等我想起来的时候我已经不记得这个模组是谁的前置依赖项了。所以我想说能不能有一个类似于apt autoremove的东西。
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting the Fabric mod metadata in fabric.mod.json and locating HMCL's mod management entry points. Define how dependency and reverse-dependency relationships should be represented, including identifying unused prerequisites, then determine how the dependency tree should be displayed and verified for Fabric mods.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- desktop, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100