Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for "subspecs" #588
I think this is possible today by tagging a branch or commit which adds certain extensions to the framework, but I'm thinking that could add a lot of complexity to pushing a release, especially when new versions of Swift are released, or pull requests are filed.
Correct me if I'm wrong, but I think this would be a good thing to be handled by the infra.
I too think that this is something that should be considered for Carthage.
A lot of projects e.g. have ReactiveCocoa as a soft dependency to add ReactiveCocoa support.
I think @jspahrsummers prefers the former way of creating a small, optional framework that e.g. adds ReactiveCocoa support, which forces projects to become much more like µFrameworks (yay!).
Another approach would be to have a project expose multiple .frameworks that are dependent on each other.
I have only quickly tested this, but to me this approach looks very promising. This way, we can still have a single project that exposes multiple frameworks. Developers that do not want to use the ReactiveCocoaExtensions simply ignore the built XReactiveCocoaExtensions.framework and are good to go.
Any thoughts or caveats towards this method?
@aschuch I agree with what you're saying. I ran into this issue with Moya. Currently, Moya's
I'm in the process of refactoring my own fork for it, where different dependencies are included and managed on separate branches (Moya, ReactiveMoya, and RxMoya). This has some pretty serious maintenance implications, and limitations for frameworks which may want to expose interfaces for certain development patterns.