Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for "subspecs" #588

Closed
justinmakaila opened this issue Jun 27, 2015 · 4 comments

Comments

@justinmakaila
Copy link

commented Jun 27, 2015

Hey guys,
I think it would be super awesome if Carthage could add support for something similar to CocoaPods subspecs. This would encourage developers to build extensions and categories on to their frameworks which add support for some of the most popular frameworks today.

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.

Thoughts?

@justinmakaila

This comment has been minimized.

Copy link
Author

commented Jun 27, 2015

This could potentially be implemented with target settings in the xcodeproj, or even binaries distributed through Carthage.

@jspahrsummers

This comment has been minimized.

Copy link
Member

commented Jun 27, 2015

No, sorry. This encourages large frameworks, which are antithetical to modularity and composability.

I'd prefer for Carthage to encourage smaller frameworks that can be used independently of each other.

@aschuch

This comment has been minimized.

Copy link

commented Jun 29, 2015

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.
At the moment, there are two options in this case:

  • Add ReactiveCocoa support in a separate project
  • Include ReactiveCocoa by default (forcing the dependency onto other developers)

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.
E.g.

  • X.framework (standalone)
  • XReactiveCocoaExtensions.framework (linking against X.framework and ReactiveCocoa.framework)

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?

@justinmakaila

This comment has been minimized.

Copy link
Author

commented Jun 29, 2015

@aschuch I agree with what you're saying. I ran into this issue with Moya. Currently, Moya's carthage build is dependent on ReactiveCocoa just for the ReactiveMoyaProvider, which may or may not be implemented by the end user.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.