Add podspec

[igor-makarov]

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.

[swift-server-bot]

Can one of the admins verify this patch?

[weissi]

Thanks for your PR! I can't take this right now yet because this claims version 0.0.1 but we haven't tagged a version yet (but will soon after Swift 5 gets released).

Regarding the podspec: Do we need to check the podspec in? We could just use a script like SwiftNIO does which automatically generates & uploads the podspecs with versions from SwiftPM. Otherwise we'll have to manage the versions in two places: the git tags for SwiftPM as well as the podspec file, no?

[chrisballinger]

@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

[weissi]

@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.

[igor-makarov]

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.

[igor-makarov]

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 swiftlang/swift-llbuild#545.

I think it covers all cases and is compatible with SwiftPM versioning, in a way. Let me know what you think!

[weissi]

Wow, this looks great. I’m +1 on this.

[weissi]

Thank you!

[weissi]

Couldn’t we sort this ‘by version’? Just in case we tag 1.2.0 and later we need to add a 1.1.2. I think sort can sort by version and git might be able to too?

[igor-makarov]

Thanks for pointing it out!

I've replaced it with a git command that correctly looks for the tags in the current commit tree only.

[igor-makarov]

This way if you have 1.2.0 and you later branch 1.1.2, if will get handled correctly.

[weissi]

Thank you, looks great to me. You might want to remove the old build_podspec script or maybe have it just use this podspec.

[igor-makarov]

I've removed the old podspec builder as suggested.

[danramteke]

Any updates on getting this merged?

[tomerd]

@weissi i know we added https://github.com/apple/swift-log/blob/master/scripts/build_podspec.sh instead, have we pushed the podspec?

[weissi]

@danramteke / @tomerd yes, the podspec is live as cocoapods.org/pods/Logging

[danramteke]

@weissi thanks for the direct link. I was not able to find it by searching "logging"

[igor-makarov]

@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.

[weissi]

thanks @igor-makarov , I was wondering why it doesn't show up.

[tomerd]

can we close this since we are already publishing a pod?

[igor-makarov]

This is an improvement to the podspec, it removes the need for a separate script.

[tomerd]

@weissi do you prefer the script or the spec file? i dont have a strong opinion

[weissi]

@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

[weissi]

@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.

[igor-makarov]

I thought that it would be nice to avoid having a generator script.
What are the modules you're talking about?

[weissi]

@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

[igor-makarov]

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.

[igor-makarov]

Did a rebase to clean up the commit history.

[chrisballinger]

@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'

[FredrikAugust]

Any updates on this?

[weissi]

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

[glbrntt]

@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]

@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?

[glbrntt]

Yes: inferring from git is one of the changes proposed by this PR.

[weissi]

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.

[tomerd]

we do version inference in the jazzy docs generation script, you can steal it from there

[ktoso]

Sounds good to me 👍

[ktoso]

I'm going to be the bearer or news and close this ticket then I guess.

2 years ago, most of projects we maintain have stopped supporting CocoaPods - https://forums.swift.org/t/swiftnio-is-dropping-support-for-cocoapods/56840 - ever since SwiftPM and its ecosystem has kept growing, and we don't have the expertise to maintain pods to begin with.

I'm going to close this PR given the above context and lack of action on it since a long time.