大家好,
我认为如果Carthage
可以添加对类似于 CocoaPods 子规范的支持,那将是非常棒的。 这将鼓励开发人员在他们的框架上构建扩展和类别,从而增加对当今一些最流行的框架的支持。
我认为今天可以通过标记向框架添加某些扩展的分支或提交来实现这一点,但我认为这可能会增加推送版本的很多复杂性,尤其是在发布新版本的 Swift 或拉取请求时提交。
如果我错了,请纠正我,但我认为这将是由基础设施处理的一件好事。
想法?
这可以通过xcodeproj
中的目标设置来实现,甚至可以通过Carthage
分发的二进制文件来实现。
不,对不起。 这鼓励了大型框架,这与模块化和可组合性是对立的。
我更喜欢 Carthage 鼓励可以相互独立使用的小型框架。
我也认为这是迦太基应该考虑的事情。
很多项目,例如将 ReactiveCocoa 作为软依赖项来添加 ReactiveCocoa 支持。
目前,在这种情况下有两种选择:
我认为@jspahrsummers更喜欢前一种创建小型可选框架的方式,例如添加 ReactiveCocoa 支持,这迫使项目变得更像 µFrameworks(_yay_!)。
另一种方法是让一个项目公开多个相互依赖的 .frameworks。
例如
我只是快速测试了这一点,但对我来说,这种方法看起来很有希望。 这样,我们仍然可以拥有一个公开多个框架的项目。 不想使用 ReactiveCocoaExtensions 的开发人员只需忽略内置的 XReactiveCocoaExtensions.framework 就可以了。
对这种方法有什么想法或警告吗?
@aschuch我同意你所说的。 我和 Moya 遇到了这个问题。 目前,Moya 的carthage
构建依赖于 ReactiveCocoa 仅用于ReactiveMoyaProvider
,最终用户可能会也可能不会实现。
我正在为它重构我自己的 fork,其中包含不同的依赖项并在不同的分支(Moya、ReactiveMoya 和 RxMoya)上进行管理。 这有一些非常严重的维护影响,以及可能希望为某些开发模式公开接口的框架的限制。
最有用的评论
不,对不起。 这鼓励了大型框架,这与模块化和可组合性是对立的。
我更喜欢 Carthage 鼓励可以相互独立使用的小型框架。