swift-log
swift-log copied to clipboard
apple
Add podspec
Hi, this PR adds a .podspec file to the package.
The podspec has been tested with a working app and is functioning.
I've also run pod lib lint which integrates the pod into a blank app target and executes its tests. This also passes.
This closes #19.
@weissi You generally need to check the podspec in because a Podfile can reference a git repo, in which case it will look in the root for a podspec.
The podspec file is expected to be in the root of the repository
http://guides.cocoapods.org/syntax/podfile.html#pod
@chrisballinger what’s wrong with the way NIO does it? The pods look just fine to me: https://cocoapods.org/pods/SwiftNIO
The reason I don’t want to check it in is that there’s then two places for the version information: the git tags and the podspec and that’s not good.
In addition to publishing the podspec in the spec repo, it is used for one more purpose: direct git pod integration. Right now, I'm referring to swift-log in my Podfile like so:
pod 'Logging', git: 'https://github.com/igor-makarov/swift-log.git', branch: 'add-podspec'
This way, the podspec is retrieved directly from the repo and the version tags are ignored, allowing for usage of latest dev version.
Hi! It's been a long time but I've been recently doing similar integration with swift-llbuild and I've gotten a new angle on the whole podspec versioning thing.
The full explanation is over at https://github.com/apple/swift-llbuild/pull/545.
I think it covers all cases and is compatible with SwiftPM versioning, in a way. Let me know what you think!
@weissi i know we added https://github.com/apple/swift-log/blob/master/scripts/build_podspec.sh instead, have we pushed the podspec?
@weissi thanks for the direct link. I was not able to find it by searching "logging"
@danramteke yeah, the search indexer on the CP website broke a while ago, and because it's a volunteer project, nobody got around to fixing it yet.
This is an improvement to the podspec, it removes the need for a separate script.
@weissi do you prefer the script or the spec file? i dont have a strong opinion
@tomerd definitely script because then there's one source of truth, right? The podspec needs to re-iterate the modules as well as the version number. So generating this from Package.swift sounds better to me
@tomerd actually, the podspec seems to be automatically detecting the version which we might be fine with. Still seems a little dangerous that you don't have to specify which version exactly to upload though. But better than nothing.
I thought that it would be nice to avoid having a generator script. What are the modules you're talking about?
@igor-makarov well, the thing is that there might be new modules in the future. In that case we'd need to remember to change both the podspec and the Package.swift. A generator script wouldn't have this issue because it uses the real source of truth which is the Package.swift. For a more complicated example check the generator in swift-nio
The current generator doesn't read from Package.swift though, right?
My original problem was that if there's no podspec in the git repo, there's no way to integrate the latest master version into a project.
@weissi This should be merged because even though the problem is semi-resolved by having a podspec version published to trunk, not having this merged prevents someone from pointing to the master branch (or another branch) on this repo. For example, this is a somewhat common workflow:
pod 'Logging', git: 'https://github.com/apple/swift-log.git', branch: 'master'
There is another option: We could check in a .podspec IF we have a script (that is run by CI) which regenerates the podspec in CI. Basically exactly like we do the LinuxMain.swift generation. If the CI detects that you haven't run the update script it fails. WDYT? @ktoso / @glbrntt / @tomerd
@weissi that sounds reasonable, would it infer the version as per this PR or would the script just have to be run after tagging a new version?
@weissi that sounds reasonable, would it infer the version as per this PR or would the script just have to be run after tagging a new version?
Oh man, I forgot about the version :. Could it use git in the podspec to find the version?
Yes: inferring from git is one of the changes proposed by this PR.
Cool! If we now get a generator script that generates exactly what this PR proposes and add that to the CI to double check it's not wrong, then I'm cool with this.