Support Swift Package Manager

[gcox]

We should support SPM before we add much more swift code. SPM doesn't support mixed language targets so it's probably best to come up with a non-painful way to support SPM now rather than waiting until there's even more swift code to deal with.

The main pain point is exposing the public headers of the C-language code.

[mickeyl]

I really would like to see that happening. I tried some approaches using submodules, softlinks and stuff, but neither one was very fruitful and at the end of the day, they would just result in additional maintenance work when the library continues to evolve.

I think the only way to get this done properly is to relayout the sources in a way that makes both Xcode and the Swift Package Manager happy. So the actual question is @robbiehanson: Would you object to such a change or not?

Although the handling of Swift Values is not optimal yet and there are no facilities for the new technologies, such as Combine and SwiftUI, I still see YapDatabase as the best database library for Swift at this point of time and would love to see it being more widely adopted.

[mickeyl]

I have created a proof-of-concept to find out whether there are additional hurdles and as a first start, it looks quite good. Please have a look at https://github.com/mickeyl/SwiftYapDatabase – more details at https://www.vanille.de/blog/2020-spmifying-yapdatabase/.

Please don't take this wrong, it's not supposed to be a fork! I'd be glad to remove this repository as soon as upstream got the appropriate treatment to make it usable via SPM.

[noremac]

@mickeyl I'm also very motivated to have SPM support here. As an experiment I tried migrating my app to the SPM version you've made and it works well, thanks for trying that! I'd like to help out here and it'd be great if we could a little direction especially with regards to the subspecs provided via CocoaPods.

I think a direct translation would be to make a new library product per subspec, but that'd mean you'd have to do:

import YapDatabase
import YapDatabaseSwift
import YapDatabaseAutoView
import YapDatabaseSecondaryIndex
...etc

Not the best, but maybe not the worst?

[mickeyl]

@noremac Thanks for your comment.

The thing is… I welcome fine granular subprojects, if, and only if, they make a difference with regards to the amount of, say, linked libraries, or when a big lump of code is included. As it stands though, with the exception of the CloudKit-Extension, these extensions are pretty lightweight (often even empty, since they don't contain any additional Swift support), so it seems to be an unnecessary complication to me.

That said, I don't have any strong feelings towards this. If we want to name the core library YapDatabase, then we need to adjust the YapDatabase.h|m, otherwise SPM gets confused with regards to the umbrella header though.

As it stands with the Objective-C open source landscape, there is obviously no general naming consensus yet. Depending on what you consider the usual case, there seem to be two approaches (with variants). Consider a library Foo:

a) Name the underlying Objective-C library with a prefix or suffix, e.g. ObjCFoo, or FooObjC, or even _Foo. Name the Swift library without any post- or prefixes, Foo.
b) Name the underlying Objective-C library without prefix or suffix, e.g. Foo. Name the Swift library with prefix or suffix, e.g. SwiftFoo or FooSwift.

In the light of more and more pure Swift frameworks becoming the norm, I'm somewhat leaning towards a). Any other opinions?

[chrisballinger]

For XMPPFramework and CocoaLumberjack, the convention there has been to use a Swift suffix for the Swift module (e.g. YapDatabase for pure Obj-C and YapDatabaseSwift for the Swift extensions). There might need to be some more modifications to support the mixed package via CocoaPods and SPM simultaneously (conditional includes of the Obj-C module). I'd also say to just lump all of the subspecs into a single SPM module because it isn't too much overhead. Renaming YapDatabase.h|m to appease the SPM umbrella header logic needs seems like the right call as well. Possibly YapDatabaseCore.h|m?

[mickeyl]

I have renamed the package as discussed. The Objective-C part can now be used via import YapDatabase.

mickeyl/SwiftYapDatabase@e1befb0

[singhmeher32]

@mickeyl Thanks for the SPM support. I am trying to use Yapdatabase in my app but I am getting an issue for the dependency which is pointing to the latest commit for Yapdatabase in the dependency tree. The error is basically related to depending on an unstable-version package ‘swiftyapdatabase’.

I found out that this error is because I am using the latest commit or the master branch, instead for a stable package version I would need a version number to mention in my Package.swift file.

.package(
name: "YapDatabase",
url: "https://github.com/mickeyl/SwiftYapDatabase",
branch: "master")

I don't see a release version/tag in here -https://github.com/mickeyl/SwiftYapDatabase
Can you help me with the release/ tag version for Yapdatabase which has Package.swift file that I can use in my app ?

[mickeyl]

@singhmeher32 I tagged it as version 2.9, which seems to be in line with YapDatabase.

[singhmeher32]

Thanks very much!

[N-ihad]

what about SQLCipher podspec support? @mickeyl could you add it too?

[mickeyl]

@N-ihad Let me check what I have to do for this to happen.

[N-ihad]

@mickeyl thank you!