Moya: Support Swift Package Manager

[ashfurrow]

https://swift.org/package-manager/

[wangshengjia]

+10000 :tada: :+1:

[justinmakaila]

I've been dabbling with this for the past hour... Does anyone have any idea how we would split up ReactiveMoya and RxMoya? I know we just went through this for Carthage, but I think this deserves the same amount of scrutiny.

In the current state, as per the swift-package-manager documentation, the sources in the Plugins/, ReactiveCocoa/ and RxSwift/ directories will be compiled as separate modules, named as their directories specify. I've attempted to embed Package.swift files within each subdirectory, but it doesn't work due to file name collisions.

EDIT I'm going to try this after lunch, but I think it might be possible if we split everything up into targets and specify the dependencies in Package.swift.

FWIW: https://github.com/apple/swift-package-manager/blob/master/Documentation/DevelopingPackages.md#working-on-apps-and-packages-side-by-side

[pmairoldi]

I think that specifying targets would be the way to go just like the example from (Package.swift documentation)[https://github.com/apple/swift-package-manager/blob/master/Documentation/Package.swift.md] . Don't know if that will cause the targets that depend on the "core" target to need to have import Moya in their source code.

[swizzlr]

The "correct" way to do this would be to provide a core "Moya" framework and then "ReactiveMoya" and "RxMoya" ancillary frameworks. Yes, you may end up needing to do two imports. You have to deal.

[justinmakaila]

@swizzlr True, but that would then break our CocoaPods and Carthage integrations.

TBH, I think this is the way to go. I know that the RAC and Rx extensions are supposed to be subspecs, but in reality, they're extensions of the library. They're built on top of it, very similarly to how Apple built the dealer example libraries.

[swizzlr]

YUP. Subspecs are a bad method of organising code.

[orta]

Creating whole repos, and all the required infrastructure for 1-2 files, then 1-2 test files is a bad method of organising code.

[tomburns]

I currently use cocoapods to integrate Moya in my projects, but subspecs are basically a proprietary notion and the library needs to be easily usable for everyone without them (and without simultaneously requiring Rx and RAC for all users, obviously).

+1 for breaking out the extensions, in the absence of any other apparent solution.

[justinmakaila]

@tomburns That's a good point. The Swift package manager is going to be distributed with all versions of Swift and Xcode in the future. There's no 3rd party software to be installed like there is with CocoaPods and Carthage. Someone who says that Moya is a dependency in their Package.swift file should not be required to also import ReactiveCocoa or RxSwift into their project if they don't use it, which they're required to do now with Carthage.

[ashfurrow]

I'd like to point out that, unlike with Carthage, we may have the opportunity here to add support for subspecs to SPM. I honestly think they're a fantastic feature, and I know the SPM/CocoaPods people have been chatting. Maybe that's something we could do together.

[orta]

They've already got something like this on their todo as Package Flavours.

[ashfurrow]

Neato :ok_hand:

[tomburns]

Nice; that'll be great if it makes it in. My major point in the previous comment was that we should probably make good support for the pending first-party package manager our top priority, even if it involves some additional overhead. If we can pull off the current structure in SPM, so much the better.

[orta]

Like all things in programming, It's a trade off, there's additional complexity in maintaining a lot of redundant resources in order to keep things going as they are now.

Ensuring that multiple projects are now green on deploys becomes harder, might need a meta-repo to allow for editing all of the files at once, changes to one might not propagate to the others via multiple PRs. This is a community project, so those tradeoffs don't have to be the ones that I think are valuable.

Switching to separate repos for all of these strongly correlated projects comes with lots of downsides, but if one of the upsides is that it can work with the current build of SPM before the add flavours, then maybe it is worth the tradeoff for someone to build and ensure all of the infrastructure is in place to simplify the extra work for contributors.

[ashfurrow]

Aye. If anyone is interested in the specifics of what's involved, check out this PR for our first attempt at a multi-repo setup, and then this PR that finally did add Carthage support (it discusses the reasons for going with only one repo).

[swizzlr]

But Orta, the projects are _not_ strongly correlated! The RAC extensions to Moya are simply extensions to provide helpful wrapping. The core value of Moya lies in its endpoint modelling types, and if the extension subspecs went away tomorrow, we would be no worse off. There will be very little requirement for lockstep updates as long as the extensions only use public API, just as they should. A strong adherence to semantic versioning would obviate many issues. I agree that lockstep repo updates suck, but that wouldn't be the case here.

[orta]

The core value of Moya lies in its endpoint modelling types, and if the extension subspecs went away tomorrow, we would be no worse off

That's idealistic, not realistic, I bet almost everyone who maintains and contributes to this project uses RAC/Rx with Moya. I had to argue that it was worth building a non-RAC version at all at the start. Again, I'm not the one who would be doing the work maintaining and keeping this all running, so it's not my neck on the line here.

[ashfurrow]

I had to argue that it was worth building a non-RAC version at all at the start

Ha, I forgot about that!

[orta]

RxSwift has done this without much faffing

[aloco]

Hi,

I went through all discussions (https://github.com/Moya/Moya/pull/169, https://github.com/Moya/Moya/pull/215) regarding multi repo setup / carthage / cocoapods and so on. But I still don´t get the point why it´s such a mess to break out Moya´s reactive extensions from the core library.

TBH the reactive stuff is _nothing more_ (like @justinmakaila and @swizzlr pointed out) than convenient extensions of the core library. Why can´t we treat them like the other Community extensions and keep things simple? I think that approach would work for Carthage, CocoaPods and SPM.

I am a Carthage user and I am using Moya together with ReactiveCocoa in _every_ project. I like it. But I don´t like to include dependencies I am actually not using (RxSwift), and I am sure RxSwift users don´t like to wait for ReactiveCocoa to build, when updating their dependencies (what happens often caused by e.g. a new Xcode release, Moya release, ReactiveCocoa release, RxSwift release, ....). If you checkout the Changelog every second release of Moya just updates it´s dependency to external libraries. Maybe this is caused by the nature of external dependencies but why should pure Moya users care about an updated ReactiveCocoa or RxSwift? Why should a ReactiveCocoa user care about RxSwift updates? They have to deal with issues caused by a library they are not using.

IMHO since everything is moving so fast with new releases, its worth the multi repo tradeoff to make developers everyday life easier / increasing (minimal) maintenance effort for contributors. Maybe I´m not experienced enough to catch all implications of moving the extensions to external repos but I can only report that I nearly always run into issues with Moya when updating my dependencies.

Sorry for reigniting this discussion 🙃✌🏼

[justinmakaila]

@aloco I'm all for that. When Xcode 7.3 dropped, I had serious issues building Moya due to dependencies not yet being updated. It's a huge hassle, especially when the dependencies that are causing issues aren't used in the project.

[AndrewSB]

Closing this conversation in favor of https://github.com/Moya/Moya/pull/643.

I didn't see this conversation when I was working on https://github.com/Moya/Moya/pull/563, but I'm glad to see other people had noticed the same problem I had 😄

Of course, please re-open this if there's anything lingering that should be discussed!