pip-reqs compile仅能解析requirements.in内多个GitHub zip依赖中的单个包

你遇到的丢包异常完全是命令中携带的--no-index参数搭配旧版pip-tools的解析逻辑缺陷导致的，和多源依赖本身的支持能力无关：

• --no-index参数的作用是强制pip完全跳过PyPI公共索引，仅从你显式声明的链接、本地路径加载所有包的元数据，不会访问线上源做依赖校验、元数据补全。
• 单远程GitHub zip依赖场景下，pip加载该包的元数据后，会顺着包内置的依赖链（比如checkout-psp-client内置的django依赖），正常把django、asgiref、pytz等关联依赖解析出来，写入requirements.txt。
• 多远程GitHub zip依赖搭配--no-index的场景下，旧版pip-tools的内存解析逻辑存在缺陷：遍历完第一个远程源的元数据后，解析器会将结果存在临时内存集合中；遍历到第二个远程源时，会直接重置该内存集合、仅加载第二个源的元数据，最终输出时就只剩第二个遍历到的远程包，整个过程不会触发任何校验报错——因为pip默认该模式下用户已经把所有需要的依赖都列全了，不会主动核查显式声明的内容是否丢失。
  这个逻辑的外在表现就是你观察到的现象：调换依赖的书写顺序，就会丢失排在前面的那个包，编译结果完全和声明顺序绑定。

根据你的使用场景选择对应方案：

• 不需要严格离线编译：去掉pip-compile命令中的--no-index参数，保留PyPI索引源参与依赖解析，多GitHub远程依赖的场景下不会出现元数据覆盖丢包的问题。
• 必须使用无索引离线编译：
  • 提前把所有GitHub远程zip包下载到本地固定目录，在requirements.in中替换为本地文件路径引用（例如./checkout-psp-client-0.0.1.zip#egg=checkout-psp-client==0.0.1），本地路径加载的源不会触发内存元数据覆盖的bug，编译时会完整保留所有声明的依赖。
  • 将当前环境的pip-tools升级到v6.0.0及以上版本，旧版本--no-index模式下处理多远程URL源的覆盖bug已经在该版本后修复。
• 调试时可以在pip-compile命令后追加-v（即--verbose）参数打开详细解析日志，即可看到解析过程中元数据被覆盖的具体环节，不存在无调试日志的问题，只是默认日志级别隐藏了该部分细节。

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