Preparing to publish SwiftPaperTrail
• Mark Eschbach
So back to my nose at the grindstone for this the SwiftyPapertral project. I’ve setup TraivsCI to build the project. I’ve noticed there seem to be two steps when building a pod:
- Ensure the example project properly builds
- Run
pod lib lint
I kept overlooking the second step, so I created the following script:
#!/bin/sh -e
set -o pipefail && xcodebuild test -workspace 'SwiftyPaperTrail.xcworkspace' -scheme 'SwiftyPaperTrail' -destination 'platform=iOS Simulator,name=iPhone 6,OS=10.1' ONLY_ACTIVE_ARCH=NO | xcpretty
pod lib lint
The pod lib lint
uncovered some errors regarding protocol conformance. I’m surprised XCode didn’t inform me. Perhaps there is a setting regarding warnings I missed. Nope, but did toggle warnings to be errors. The problem stems from a protocol requiring variable getters and setters. I don’t really care about the value here, so I’m wondering if I can ask Swift to generate these for me. Quick search didn’t turn anything up. So onto using the shadow variable techinque to deal with this. I’m really surprised that Swift doesn’t have a mechanism to deal with this naturally; probably does and I’m overlooking it. Hmm…the linting is still returning the same thing. So I think it might be time to dig into the docs to verify it’s trying to lint the current state of the code since it’s complaining about something which doesnt’ make sense.
According to CocoaPod’s Deployment docs pod lib lint
is correct since it doesn’t access the remote repo. Looking at CocoaPod’s pod lib lint docs don’t show any smoking guns. I’m going to try to force the Swift version to 3. Seems to have accomplished nothing at all. All well.
Since I can’t figure out why I’m receiving this error I’m going straight for modifying the traget repository; hoping I can figure out what is going on here. Probably something to do with access rules I’m not quiet understanding is my current hypothesis. Unforunately Apple’s documentation is not really conclusive regarding Swift 3’s access controls and module dependencies. On to modifying the source library to see if I can source the underyling issue. First up, marking the target interface with open. No dice there.
Using the --no-clean
flag doesn’t nuke the failed workspace, making diagnostics possible. Looking at the application, it definitely has some problems. The body of the implementation is blank. This is an old file that I deleted a while back which souldn’t be there. Hmm. Running the lint
command with --verobse
and piping to a file reveals the correct repository on my disk is being pulled. There is an interesting warning saying the project should use the App.xcworkspace
instead of the project. Tried tagging the current version and that didn’t shake out the file. Well, I think I found the proble, there was a file floating around which I removed from the project but was picked up by the podspec
due to file globbing. Also learned the test script should do pod install
to ensure it runs from a clean repo state. So that was a fun problem. Simply deleted the file and it’s done.
Overall I’m fairly impressed with Travis’ donation of OSX executor time to open source projects. For many cloud CI systems hold fast to OSX being a premium feature that is really awesome. Despite a few hickups over the last month I’ve found Travis CI to be a much better expierence than CircleCI. Now just waiting for the executor to verify my build…And failed. Apparently the CocoaPods needs to be updated on Travis first. All well, probably for the best anyway.
While waiting for that I’m back on Swift 3 upgrades. I’m attacking the tests to see if we can get them to stablize. This will be exciting.
Alrighty, missing module. Firebase
appears have majorly changed with their Swift 3 upgrade. I came across a video of someone showing off how to setup Firebase under Swift 3…sigh; really? Just give me the text! Turns out the module name changed to FirebaseCore and friends, although the friends aren’t stated there.
Refocusing to getting all of tests (unit + integration) up and running again. We have a core algorithms library which needs to compile first. Needed to modify some schemes and drop the ref to primary build product (strange the tests got linked against them). Interesting in Swift 2 series we didn’t get an ambigious method invocation, but under Swift 3 it did. Good catch Swift 3! Sigh, back to dealing with optionality + comparison. I really wish they would just choose a way to move forward and be done with that debate.
Hmm, in one case I have a class with a handful of callbacks. I defaulted to my Java like ways with a nested protocol describing the the interface. Apprently it’s only enums are the type of thing which can be nested. Okay, on to optiaonl functions in protocols. Ah man, protocols can’t have optional methods without being Objective-C classes. Grump! Well that leaves me with many fewer design choices. Hmm, what was that GoF pattern called? Apparently there isn’t a default implementation thing in GoF. Or actually, it’s easier to just to have an open
protocol.