Open ben-xD opened 3 years ago
@QuintinWillison @AndyNicks I'm here after looking at #1070. Do we know whether we'd like to proceed with removing Carthage? Do we have a sense of how disruptive this would be to users of the library?
I've had a quick look through all issues mentioning 'carthage', where most of those only mention it because we were using an issue template that pretty much every issue creator said 'No' to the question 'Are you using Carthage?'.
There is no way, that I'm aware of, for us to get any metrics around use of this SDK via Carthage as it uses GitHub as the natural distribution platform innately.
Ideally I would have us drop Carthage support in a minor
, perhaps major
, version bump - however, the work to progress us towards enabling that versioning freedom for all SDKs has not yet been completed. I also know that keeping Carthage in the mix is holding this codebase back from a maintainability standpoint.
I think we should proceed with removing Carthage from this codebase now and accept the risk that we'll be doing this as part of a patch
version bump, which may well attract complaint from developers who are bringing this SDK in via that route.
What will put us in a good place to handle those complaints will be for any work that is done to remove Carthage under this issue to also include some documentation describing any hints or steps they can go thru in order to put our preferred replacement in place (presumably, SPM).
Just happened to be passing by here - one thing to mention is that we should probably do this as a few separate pieces of work (for ease of review):
swift test
(this might actually need to come first, since Nimble, which is a dependency of our test suite, is currently brought in using Carthage).xcodeproj
Background
As part of adding SPM support, a
Package.swift
was added to Ably cocoa, allowing Xcode projects and other swift packages to easily add Ably as a dependency. Swift packages are separate entities to Xcode projects, and do not co-exist with Xcode projects very well:Package.swift
, and so we have to sources of configuration which can diverge in the future.swift package generate-xcodeproj
has been deprecated, which was previously used to generate an ephemeral Xcode project based on thePackage.swift
so that you can still open the Swift Package as a Xcode project. It no longer has the updates.Tasks:
In @lukasz-szyszkowski's PR, we are keeping the Ably.xcodeproj temporarily to avoid making too many changes. But these changes should happen soon to avoid developer confusion:
Ably.xcodeproj
, relying solely onPackage.swift
for configuration (and other automatically generated files.swiftpm
). Xcode schemes are autogenerated based on thePackage.swift
..xcodeproj
to build the output framework. Therefore, we can delete a lot of carthage related files (Cartfile/ .resolved), lines related to updating carthage dependencies in the.github
yaml. We can remove references from Carthage.swift build
instead ofxcodebuild
, or modify existingxcodebuild
code to automatically use the autogenerated schemes fromPackage.swift
.