Python包依赖platform_release标记在Bazel安装时触发InvalidVersion异常的解决方法

针对你遇到的platform_release版本字符串不符合PEP440规范导致Bazel安装报错的问题，可以通过以下几种方式规避：

1. 限定系统后再做版本判断 #

把依赖标记修改为仅针对macOS系统做版本校验，这样Linux等其他系统不会触发版本字符串的解析逻辑，自然不会报错：

'scipy >=1.7, <2; platform_system == "Darwin" and platform_version >= "21.0.0"'

这里platform_system == "Darwin"先锁定macOS系统，再用platform_version做版本判断——macOS的platform_version返回值是符合PEP440规范的（比如Big Sur对应21.0.0），不会触发解析异常。

2. 将依赖设为完全可选，移至运行时校验 #

如果环境标记的方式始终有兼容问题，可以彻底放弃安装阶段的依赖标记，把scipy设为可选依赖，然后在包的运行代码里做兼容性校验：

• 在setup.py或pyproject.toml中把scipy设为可选（比如用extras_require）：

  # setup.py示例
  setup(
      # ...其他配置
      extras_require={
          'optional': ['scipy >=1.7, <2']
      }
  )
  

• 或者直接不做安装阶段的版本限制，在代码中动态处理：

  try:
      import scipy
      from packaging.version import parse
      # 校验scipy版本
      if parse(scipy.__version__) < parse("1.7"):
          raise ImportError("需要scipy 1.7或更高版本")
  except ImportError:
      # 降级逻辑：比如使用替代实现或提示用户安装
      scipy = None
      print("警告：未检测到符合要求的scipy，部分功能将无法使用")
  

这种方式把兼容性检查从安装阶段移到运行阶段，彻底避免安装时的版本解析问题。

3. 自定义Bazel规则（针对Bazel用户场景） #

如果主要问题集中在Bazel用户，可以建议他们在Bazel构建配置中忽略该依赖的标记校验，或者自定义规则处理版本字符串的解析，但这种方式需要用户配合修改构建配置，不如前两种方案通用。

问题根源说明 #

platform_release字段的返回值由Python的platform模块决定，不同系统的格式差异极大：macOS返回规范的版本号，但Linux会返回类似6.5.0-172-generic的带后缀字符串，不符合PEP440的版本规范。而Bazel使用的pkg_resources会严格按照PEP440解析版本字符串，因此触发InvalidVersion异常。PyPA的立场是环境标记中的版本比较必须符合PEP440规范，所以需要调整你的依赖标记策略，避免对非规范版本字符串做比较。

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