How to include licenses of Swift packages

[martnst]

Hey there,

not sure if I just missed it in the docs... is there any way of automatically including the used swift packages as well.

In my App, I have only 2 dependencies left on Cocoapods while the rest are migrated to SPM. Would be great if it was somehow possible to mix both.

Cheers

[vtourraine]

Hello Martin, and thanks for your question!

Unfortunately, you’re right: there’s no way to automatically include the SPM list of dependencies for a given project with AcknowList. Right now, you need to either hard-code the list (as an array of Acknow instances), or create a plist similar to what CocoaPods is generating, and use the auto import.

But that would be my top-priority feature request for AcknowList. The problem is that I’m not sure how to do it.

To my knowledge, the best solution to find the list of resolved dependencies is to look at [appName].xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved, as hinted on https://developer.apple.com/documentation/swift_packages/building_swift_packages_or_apps_that_use_them_in_continuous_integration_workflows (it doesn’t include local packages, though). So maybe we’d have to import that file into the main target, like we do for the CocoaPods plist? That gives us the list of packages with names and URLs, but not the licenses. Should we try to somehow fetch the licenses from each repo? When compiling, or when running? Or just open the repo instead of the license?

I know, lots of questions, but again, I think that’s the next step for AcknowList, as SPM seems to slowly overtake CocoaPods.

[martnst]

Hi @vtourraine,

thanks for sharing your thoughts on this.

I understand now, it's tricky. I guess there is even no one-single-way of providing a license text as a Swift Package. However, having / including a list of packages is a good staring point & better than nothing, I would say.

Generally speaking, I am a big fan of simply baking such kind of stuff into the app. So gathering everything at build time. However, fetching various license texts on every build sounds horrible. Taking into consideration that this process may even attempt different patterns such as $repoBaseUrl/blob/master/LICENSE vs. $repoBaseUrl/blob/master/LICENSE.txt vs … and so on, only makes it worth. So if done at build-time some sort of caching would be needed. With that, we are almost at the plist file approach. For a plist file, some script could help to build it, but this would still be clunky as dev would have to take care of running at appropriate times.

Here is another idea:

1. Gather the list of Swift packages from the Package.resolved file and include them in the list of AcknowListViewController.
2. Then have a dedicated details screen for SwiftPM packages, which would display the data points we get from Package.resolved. This details screen could link to the GitHub project of package being displayed. One could take it from there.
3. To take this one step further, this details screen's ViewController could attempt to fetch the LICENSE[.txt] (whatsoever) from the packages repo. If none of the fetching works, it may just fail gracefully. I would include some sort of loading state while the license text is search for.

Regards, Martin

[vtourraine]

Alright, let’s do this 🚀

I’ve added a new branch: https://github.com/vtourraine/AcknowList/tree/parse-packages

Right now, it only parses the titles and repository URLs from Package.resolved files (I’ve actually found 2 different formats for those files). I’ll try to implement the rest later. It does change the model a little bit, so in theory this should be released as a major new version. I’ll try to find a nice programming interface to make it as easy-to-use and discoverable as possible, despite the added complexity of supporting multiple file types.

[martnst]

🤩 Awesome!

Lemme know if there is anything I can help you with.

[vtourraine]

Alright, I’ve opened a pull request with the new SPM support (with Package.resolved files): #102.

There’s also a good amount of refactoring, especially around AcknowParser to manage the fact that we support multiple file types. Please give it a try, and let me know what you think. 🙌

[martnst]

Hey @vtourraine,

I just gave it a first try and it works great so far.

However, I am facing a crash on my private Swift packages, see https://github.com/vtourraine/AcknowList/pull/102/files#r893423676 pls.

For me, it is easy to work around this by simply filtering my private packages, which I am about to do anyways. However, you may wanna add some kind of a URL validation to prevent client apps from crashing?

Cheers, Martin

[martnst]

Hey @vtourraine how are things going on your side?

I think PR #102 is done now, thus can get merged and eventually released.

Bests, Martin

[vtourraine]

Hello Martin, and thank you for your message. You’re right, the PR should be ready. I just didn’t have the time recently to check everything (documentation, breaking API changes, etc). I’ve blocked some time for next week, it should be merged then. Cheers 🙌

[vtourraine]

Update: it’s now merged into main 🎉

As previously discussed, this will be a “version 3” update, given the amount of interface changes. I’m thinking of releasing it alongside Xcode 14 in September. Probably not much that will change because of iOS 16/Swift 5.7 per se, but that’s always a nice time to move things forward.