Closed kiliankoe closed 7 years ago
Hmm, on second thought, possible subdependencies are possibly not compatible with one of the dependency managers or versioned differently throughout, making this even harder. Pulling the source directly and nailing them to that version might probably be the only way 😕
I actually think CocoaPods, Carthage and SPM all support defining dependencies for your framework. SwiftPlate only generates your project initially, how you choose to work with it after that is completely up to you - you can add a Podfile
, Cartfile
, etc. or specify dependencies in your Package.swift
🙂
A dependency would then have to be specified throughout all three though, wouldn't it? Otherwise my build will probably work with my tool of choice, but might not for someone else using something different, if I'm not mistaken.
What about that weird dance with the symlinked .xcodeproj for Carthage compatibility Cocoapods does when creating a new pod. Would something like that also be necessary here? 😕
Yeah exactly, you'd have to use dependencies that are available on all popular package managers, if you want to support all of them. Since I haven't used Cocoapods for dependencies in frameworks myself, I'm not sure how well they would play together. Maybe @zenangst knows? 😄
So, at @hyperoslo, we haven't really jumped on the SPM
just yet. What we do to support both Cocoapods
and Carthage
is to add a Xcode project in the root folder that runs handles tests. And then we use Cocoapods
for all the examples projects that we add. Dependencies for Carthage
is handled with the root Cartfile
and dependencies for Cocoapods
is handled using the podspec.
We haven't really run into any situation where one of our sub dependencies were not available by on either Carthage
or Cocoapods
, might have to do with us creating most of the sub dependencies ourselves.
Hope that helped to clear things up.
You can find our take on generating packages here: https://github.com/hyperoslo/swiftpackage </shameless self-promotion>
So doesn't sound like SwiftPlate needs to do anything specific to support this. @kiliankoe does that answer your question? 🙂
It does, thanks both of you! 😊
I've run into the problem of trying to make my frameworks available for every dependency manager out there a few times and have mostly resorted to throwing SPM out the door, I'd love to get that working though! 😄
Not sure if I'm being stupid here or not, but what's the best way of managing subdependencies with this? For Cocoapods I could specify them in the podspec via
s.dependency ...
but can't really install them without a Podfile (something that would require an .xcworkspace as well).Also those using the framework project built like this will probably have to use my dependency manager of choice as well, which is far from ideal. Is there a way to work around this? Or is it just not practical working with subdependencies when making a framework for use with all three currently used dependency managers?