MNE-Python核心依赖项优化：精简系统信息报告中的非必要包

在MNE-Python项目的最新讨论中，开发团队对系统信息报告(mne.sys_info())中显示的依赖项进行了深入探讨。当前实现将jinja2和pooch等包归类为"Core"核心依赖项，但实际上这些包属于基础设施支持类库，而非数据处理核心组件。

当前依赖项分类存在的问题

MNE-Python的系统信息报告目前将依赖项分为几个类别：

1. Core(核心)：包含mne、numpy、scipy、matplotlib等
2. Numerical(数值计算可选)
3. Visualization(可视化可选)
4. Ecosystem(生态系统可选)

问题在于"Core"部分包含了jinja2(模板引擎)和pooch(数据下载工具)这类基础设施支持包，而同样重要的其他基础设施包如decorator、lazy-loader、packaging和tqdm却未被包含。这种不一致性可能导致用户对核心功能边界的误解。

优化建议与解决方案

技术团队提出了两种优化方案：

1. 将jinja2和pooch移至新的"Infrastructure"(基础设施)分类
2. 完全从系统信息报告中移除这些基础设施包

第一种方案保持了信息的完整性但增加了分类复杂度，第二种方案则更加简洁，专注于展示真正影响核心功能的依赖项。技术讨论倾向于第二种方案，因为：

• 保持"Core"部分只包含数据处理核心组件(numpy/scipy/matplotlib等)
• 避免过度展示实现细节
• 与其他科学计算库的做法保持一致

技术实现考量

从技术实现角度看，这一改动涉及：

1. 修改sys_info()函数的输出逻辑
2. 确保文档中明确说明完整依赖关系
3. 保持向后兼容性

值得注意的是，jinja2虽然被列为核心依赖，但实际上只在HTML模板生成中使用，且采用了延迟导入策略，这进一步支持了它不应作为核心依赖展示的观点。

对用户的影响

这一改动对最终用户的影响微乎其微：

• 不会改变实际功能可用性
• 使系统信息报告更加聚焦
• 减少新用户对依赖关系的困惑

开发团队强调，这只是一个展示层的优化，不会影响包的实际依赖关系或功能实现。

总结

MNE-Python团队持续优化项目的依赖管理策略，这次对系统信息报告的改进体现了对依赖项分类的精细化管理思路。通过精简"Core"部分的展示内容，可以使开发者更清晰地理解库的核心架构，同时保持基础设施支持的灵活性。这种改变也符合Python生态中常见的最佳实践，即在保持功能完整性的同时提供清晰的API边界。