https://duan.ca/tag/swift-package-manager/ <p>There are several ways to build dependencies for a Swift 3 project: Swift Package Manager, Cocoapods, Carthage, etc. Many have an opinion on which is the best choice for their projects. As a library author who want to help as many people as possible, however, they can't ignore any of them.</p> <p>I sometimes question the sanity of that conclusion: instead of becoming an export in each package manager, I find myself a novice of all. Did I break support for any of them with this project change? Is it still working on a particular platform, say, tvOS? Can I <em>really</em> know?</p> <p>The only way to <em>really</em> know is to verify yourself: both Cocoapods and Carthage support four platforms -- iOS, macOS, watchOS, tvOS; Swift Package Manager only works on Mac or Linux. So that's 2*4+1=9 targets. All these targets need is have the library in question fetched and imported. Every Swift library author should have such verification before publishing updates of their project.</p> <p>The steps to verify can be triggered with commands: fetch and build dependencies, build Xcode/Swift project. To automate the process, put these commands in a script or a Makefile. But wait, there's more! One shouldn't have to create these dummy projects every time they create a new library. If all these projects do is importing a library and attempt to build, they should work for <em>any</em> library. The config in <code>Package.swift</code>/<code>Cocoapods</code>/<code>Cartfile</code> and the <code>import</code> statements just needs some strings replaced: name of the next library, URL for its git repository, etc. And that's a scriptable process as well!</p> <p>To recap, one could, in theory, copy in some dummy projects, run a command to inject information about a new library, run another command to build all these project, verifying that support for those package managers remain functional.</p> <p>In reality, I have created <a href="https://github.com/dduan/DistributionTests">DistributionTests</a> and put it on <a href="https://github.com/dduan/DistributionTests">Github</a> 😉.</p> <p>The script <code>customize</code> requires 3 pieces of information of the library: its import name, its git repository URL and a major version number. The assumption here is the library generates uniformly named artifacts: the file name for <code>.framework</code> and the name users use to import it are the same. Testing distribution of a library is as simple as:</p> <ol> <li>clone the project.</li> <li>customize the project with <code>customize</code>.</li> <li>run <code>make</code>.</li> </ol> <p>If you do step 1 and 2, include the projects in library's repository, then only step 3 is necessary! This makes testing distribution methods trivial on a continuous integration server.</p> <p>Go forth and create fearlessly!</p> Mon, 10 Oct 2016 10:34:49 -0700 https://duan.ca/2016/10/10/distribution-tests/ https://duan.ca/2016/10/10/distribution-tests/