I'd like to start using SwiftPM inside Carthage. Carthage has always been automation on top of other tools (git, xcodebuild, etc.), so I think building on the work of SwiftPM makes a lot of sense.
In particular, I'd like to:
Use SwiftPM's dependency resolver. Carthage's has never been great. Rather than write/maintain our own, I think we could benefit from using SwiftPM's.
Let dependencies use SwiftPM's package descriptions instead of using a Cartfile.
Using the SwiftPM resolver would be the biggest win. But I think both of these things (and others) would help in an eventual transition from Carthage to SwiftPM. (I'm definitely hoping that SwiftPM will subsume all Carthage use and have been trying to push Carthage in that direction.)
Currently, the Swift Package Manager is packaged as a command line interface, exposed as a subcommand of the swift command. In the future, we would like to make it available as a library with a clearly defined API, so that other tools can more easily be built on top of it.
Is SwiftPM at the point where we could build on it as a library? It doesn't have an Xcode project and doesn't seem to have semantic version releases. But if we built Carthage with SwiftPM with SwiftPM as a dependency, would that be likely to work? Are there any caveats we'd need to be mindful of? (I'm not worried about breaking API changes.)
I don't think using the command-line is an option unless we force all dependencies to start using SwiftPM package descriptions—SwiftPM would have no way to resolve versions because it wouldn't know how to get information from the Cartfile.
First of all, this sounds awesome, thanks for doing this!
We have a library interface to the major parts of SwiftPM, called libSwiftPM, exposed as a package here. You could also use the "./Utilities/bootstrap" script in the SwiftPM repository to build the dylib and integrate that way. If you are using the second approach, you'll also have to include the llbuild framework.
With this, you should be able to accomplish your second objective, but I don't think SwiftPM's dependency resolver is necessarily set up to be used by a third party package manager right now.
I'm trying to make some progress on this, but might have some trouble because libSwiftPM is explicitly specified as a dynamic library target. That makes integrating with Carthage more difficult because libSwiftPM.dylib needs to be vended with carthage.
Is there a reason that libSwiftPM needs to be a dylib?
Not really. This issue has come up before but we can't change the existing product since that may break clients. We can expose a new static product but we'll need to come up with a name for it. Maybe libSwiftPM-static?
This sounds like a great direction, Matt! Our intent is for libSwiftPM to be a great interface for tools that want to build on top of SwiftPM. And given the large existing base of Carthage (and CocoaPods) packages, work that eases developers’ transition into adopting SwiftPM is worthwhile.
We appreciate any JIRAs (or PRs!) for limitations you run into with libSwiftPM.
Edit: Personally, I don’t like using file extensions to denote a file’s type instead of metadata like the old classic Mac OS. I’m like 98% sure I’ve lost that battle, though, so we might as well embrace it?