如何不导入poetry即可校验poetry lockfile锁定文件的新鲜度

现有代码的问题根因 #

• 未做依赖配置标准化：poetry计算content-hash前会将所有简写形式的依赖声明（比如字符串版本号、git依赖简写等）统一转换为结构化字典，相同语义的不同写法会被处理为完全一致的结构，直接使用pyproject原始内容计算哈希必然不匹配。
• 空值处理错误：如果_relevant_keys中的配置项不存在，现有代码会将None值放入待哈希字典，poetry官方逻辑是直接忽略不存在的配置项，不纳入哈希计算。
• 序列化规则不匹配：现有代码使用json.dumps做序列化，poetry内部使用自定义的嵌套结构序列化逻辑，保证排序、格式完全一致，两者规则不兼容。
• 依赖组处理不完整：仅直接读取group字段原始内容，没有对各组下的依赖做和主依赖相同的标准化处理。

最优修复方案 #

直接调用poetry-core提供的官方逻辑实现，不需要自行重写哈希计算规则，避免后续poetry版本迭代后规则变更导致失效：

from poetry.core.factory import Factory
from poetry.core.packages.locker import Locker
import toml

def is_poetry_lock_fresh(pyproject_path: str, lockfile_path: str) -> bool:
    # 读取配置文件
    with open(pyproject_path, "r", encoding="utf-8") as f:
        pyproject_data = toml.load(f)
    with open(lockfile_path, "r", encoding="utf-8") as f:
        lock_data = toml.load(f)
    
    # 调用官方逻辑生成标准content hash
    package = Factory().create_poetry_package(pyproject_data)
    calculated_hash = Locker.get_content_hash(package)
    
    # 与lock文件存储的哈希对比
    lock_hash = lock_data.get("metadata", {}).get("content-hash", "")
    return calculated_hash == lock_hash

如果确实需要完全手动实现哈希计算逻辑，需要补充以下处理步骤：

1. 对所有主依赖、分组依赖做标准化转换，将非结构化的依赖声明统一转成结构化字典
2. 过滤所有值为None的配置项，不纳入待哈希内容
3. 递归对所有嵌套字典做key排序，同步匹配poetry的列表排序规则
4. 使用与poetry完全一致的序列化方式生成待哈希的字节流

内容的提问来源于stack exchange，提问作者ChickenWing