用 :podspec 引用方式 也可以切换二进制组件

[su350380433]

如果把你这边的这段话，改下的话 用 :podspec 这样的引用方式就能正常切换二进制了。 你这句话是处理 developments 用的吗？ developments组件的判断可以换个过滤条件吗？

# developments 组件采用默认输入的 spec (development pods 的 source 为 nil)
unless rspec.spec.respond_to?(:spec_source) && rspec.spec.spec_source
    next rspec
end

[su350380433]

如果把你这边的这段话，改下的话 用 :podspec 这样的引用方式就能正常切换二进制了。 你这句话是处理 developments 用的吗？ developments组件的判断可以换个过滤条件吗？

# developments 组件采用默认输入的 spec (development pods 的 source 为 nil)
unless rspec.spec.respond_to?(:spec_source) && rspec.spec.spec_source
    next rspec
end

如果是 developments 组件的话用 BinProdfile 下的 use_source_pods 过滤 可以吗？ 或者判断podspec的path 不在Local Podspecs文件夹里面

刚改代码，试了下，是能实现，不知道是否还有什么遗漏的地方，或者没考虑到的情况。 对ruby不熟，还望指教。

[tripleCC]

如果把你这边的这段话，改下的话 用 :podspec 这样的引用方式就能正常切换二进制了。 你这句话是处理 developments 用的吗？ developments组件的判断可以换个过滤条件吗？

# developments 组件采用默认输入的 spec (development pods 的 source 为 nil)
unless rspec.spec.respond_to?(:spec_source) && rspec.spec.spec_source
    next rspec
end

如果是 developments 组件的话用 BinProdfile 下的 use_source_pods 过滤 可以吗？ 或者判断podspec的path 不在Local Podspecs文件夹里面

刚改代码，试了下，是能实现，不知道是否还有什么遗漏的地方，或者没考虑到的情况。 对ruby不熟，还望指教。

是可以，如果源码 source 里面找不到组件找不到，最终会走到这个分支返回原 spec。不过还是建议把组件挪到内部私有源，不建议通过走 :podspec ，考虑到下载速度及lint便捷性

rescue Pod::StandardError => e
  # 没有从新的 source 找到对应版本组件，直接返回原 rspec
  missing_binary_specs << rspec.spec if use_binary
  rspec
end

[su350380433]

如果把你这边的这段话，改下的话 用 :podspec 这样的引用方式就能正常切换二进制了。 你这句话是处理 developments 用的吗？ developments组件的判断可以换个过滤条件吗？

# developments 组件采用默认输入的 spec (development pods 的 source 为 nil)
unless rspec.spec.respond_to?(:spec_source) && rspec.spec.spec_source
    next rspec
end

如果是 developments 组件的话用 BinProdfile 下的 use_source_pods 过滤 可以吗？ 或者判断podspec的path 不在Local Podspecs文件夹里面 刚改代码，试了下，是能实现，不知道是否还有什么遗漏的地方，或者没考虑到的情况。 对ruby不熟，还望指教。

是可以，如果源码 source 里面找不到组件找不到，最终会走到这个分支返回原 spec。不过还是建议把组件挪到内部私有源，不建议通过走 :podspec ，考虑到下载速度及lint便捷性

rescue Pod::StandardError => e
  # 没有从新的 source 找到对应版本组件，直接返回原 rspec
  missing_binary_specs << rspec.spec if use_binary
  rspec
end

挪到内部私有源是个不错的做法 但可能对我们公司目前多个项目，多个业务线在跑的话，会有些分支依赖问题。目前公司有七八个项目，一百多的库，暂时没想到更好的处理它们的办法。