Moya have four submodule, Moya/Core, Moya/RxSwift, Moya/ReactiveCocoa and Moya/ReactiveSwift, the default submodule is Moya/Core. (Moya/ReactiveCocoa and Moya/ReactiveSwift have the same meaning, maybe we do not need Moya/ReactiveCocoa any more . )
Now they are in one repo, maybe we can made them separate , for example, Charts used to have two sub submodule, Charts/Core and Charts/Realm, but the author separate them to two dependent repo , Charts and ChartsRealm , in a few month ago.
I think in this way we can make Moya simple and reduce dependency problem.
Are there any dependency problems? What would the benefits of having a separate repository be for each submodule? I think having a separate repository per submodule introduces quite some challenges without solving any problems.
On Moya/ReactiveCocoa and Moya/ReactiveSwift: yes, it might be time to remove the ReactiveCocoa subspec. It has been left after the rename for compatibility with Podfiles using Moya/ReactiveCocoa. The only downside is that we can't really inform those users that there is a new subspec name, and I am not sure how big the impact could be. They would basically get stuck at a maximum library version when we would remove it, without being warned of any new versions in any way.
A similar discussion happened in #345.
Couple of quotes:
https://github.com/Moya/Moya/issues/345#issuecomment-183493154
The only "real" fix for this is to have separate repos but we decided to not go that way in the past since it adds a lot of complexity for 2 extra files.
https://github.com/Moya/Moya/issues/345#issuecomment-183494797
we tried multiple repos but it got out of hand, quickly.
But I'm interested to hear what kind of dependency problems you're referring to.
@BasThomas
@pedrofjfmartins
YES, you are right, stabilization is one of the most important things in our work.
I just said reduce dependency problem, forgive me, the statement is not exact, it's my fault, what I want to say is that separate repo can make dependency simple. For example, separate repo can reduce Carthage's built time, and each submodule would have their specific demo, maybe this is more convenient for user.
You can have a look at https://github.com/danielgindi/Charts/issues/1756 .
@petester42 How do you think about this ?
@Huang-Libo I can see the benefits it would bring for Carthage users, but I still agree with the conclusions from #345: the complexity it would add on maintenance side is too big. (more context in #215 and #169).
@Moya/contributors Thoughts?
Yeah, same. Separate repos would help Carthage users but introduce a tonne of complexity for contributors. From my perspective, I would prefer to keep contributing to the library as easy as possible.
If we do decide to change the infrastructure of the project, I'm happy to help in any way I can. Just let me know;.
I agree that there exists a problem for Carthage users, but in my opinion this is a Carthage issue, which is why I just started the discussion with my suggestion here on that topic on the Carthage side again. I hope the reactions (starting with this) are going to develop into the right direction.
So, I see the need for faster build times and I agree that we should not add additional maintenance costs just to work around an issue of a package manager. Problems should be solved where they lie.
I am going to close this for now as per the above comments, but thanks for bringing this up @Huang-Libo!
Most helpful comment
Yeah, same. Separate repos would help Carthage users but introduce a tonne of complexity for contributors. From my perspective, I would prefer to keep contributing to the library as easy as possible.
If we do decide to change the infrastructure of the project, I'm happy to help in any way I can. Just let me know;.