CocoaPods support

[ypopovych]

Hello!

Thanks for an incredible library!

I want to use it in the https://github.com/tesseract-one/ScaleCodec.swift library as a dependency for BigInt/UInt types. But we need CocoaPods support.

I understand that CocoaPods is an old tech, but it works and some techs like ReactNative or KotlinNative depend on it.

Can I create PR with Podfile and the needed fixes for proper CocoaPods publishing? I will also add GitHub action for automatic publishing on the release.

Thanks, Yehor.

[oscbyspro]

CocoaPods is still around? Somebody, please put it out of its misery.

Anyhow, I can look into it. Or, if you're willing to do the work—that'd be cool.

Cheers, Oscar.

[ypopovych]

Yeah. Understand you. But they are half-dead, not fully dead yet. Because SPM doesn't have all the features (plugins are good, but have problems).

[ypopovych]

Added in PR: #56

[ypopovych]

About StaticBigInt feature.

For CocoaPods, theoretically, it can be added as a Subspec. So dependency can be added as pod 'Numberick/StaticBigInt' '~>0.8.0' and it will enable SBI for the library. Should work, but never tested with the swift version and platform changes in the Subspec.

If it will work - CocoaPods release can support both at the same time

[ypopovych]

For Package.swift maybe it can be done through SPM plugin

[oscbyspro]

That's neat, but I want to minimize complexity and not special-case StaticBigInt too much.

[oscbyspro]

Zzz. https://github.com/oscbyspro/Numberick/actions/runs/5918950282

Encountered an unknown error (Unable to find a specification for `Numberick-NBKCoreKit (= 0.10.0-alpha)` depended upon by `Numberick-NBKDoubleWidthKit`

[ypopovych]

Because you can't lint them this way. For proper linting I created local CocoaPods repo, pushed dependencies in it and linted last one library. You can find it in the original script

pod push does a linting too.

[oscbyspro]

Is there a reason why this does not work? Asking for a CocoaPods n00b.

Edit: I changed the sources and gave it a special tag. It downloads the spec, but complains it can't find it:

spec.source = { :git => "https://github.com/oscbyspro/Numberick.git", :tag => "CocoaPods-v0.10.0-alpha" }

[ypopovych]

CocoaPods expect all libraries' specs to be pushed to the centralized repo. They are not decentralized (same as npm, pip, gems, etc.) So when it tries to lint library it searches for its dependencies on the repos, and can't find them.

[oscbyspro]

Hm. I see this in my pod repo with pod repo list:

oscbyspro-numberick
- Type: git (tags/CocoaPods-v0.10.0-alpha~1)
- URL:  https://github.com/oscbyspro/Numberick
- Path: /Users/.../.cocoapods/repos/oscbyspro-numberick

Does that not count? Do I need each podspec too?

[oscbyspro]

I suppose it got there with this, but the lint still failed:

pod spec lint --allow-warnings --fail-fast --sources="https://github.com/oscbyspro/Numberick" Numberick-NBKDoubleWidthKit.podspec

[ypopovych]

I suppose it got there with this, but the lint still failed:

pod spec lint --allow-warnings --fail-fast --sources="https://github.com/oscbyspro/Numberick" Numberick-NBKDoubleWidthKit.podspec

And it will fail. It needs a repo with a special structure managed internally by CocoaPods. It's not your repo.

[ypopovych]

When it lints the second library it expects that the first one is already pushed to the centralized repo. While linting the second one it will download sources for the first one to the temp directory for lint and build it from these sources.

In my script, I zipped sources and changed the URL to this file (to avoid redownloads), and then pushed dependencies to the local CocoaPods git repo (made from a temp folder). This way it works best (because it will emulate the proper installation of the dependencies).

You can try the second option - the --include-podspecs parameter. It will include local pod specs as :path specs. Though it can break builds or fail on the real pushing (because :path allows more features than proper URL-based include. It is meant for debugging/development). That's why I did it in a more complex way with local temporary podspec repo

[ypopovych]

But I think in your case the second option could work. Your library build is not a complex one with binary dependencies.

Try this command:
pod spec lint --allow-warnings --fail-fast --include-podspecs Numberick-NBKCoreKit.podspec Numberick-NBKDoubleWidthKit.podspec

[oscbyspro]

Hm. It's says [!] Unknown option: --include-podspecs. Regardless, I appreciate your explanation. I'll have a look at my options when I wake up tomorrow. It's a bit late at the moment.

[ypopovych]

My bad. It should be with =

pod spec lint --allow-warnings --fail-fast --include-podspecs=Numberick-NBKCoreKit.podspec Numberick-NBKDoubleWidthKit.podspec

for the third one maybe will work something like
pod spec lint --allow-warnings --fail-fast --include-podspecs=Numberick-NBKCoreKit.podspec,Numberick-NBKDoubleWidthKit.podspec Numberick.podspec

[oscbyspro]

Yer a wizard, Yehor. The following works, using lib lint and \{<podspecs>\}:

pod lib lint Numberick.podspec \
--allow-warnings \
--fail-fast \
--include-podspecs=\{Numberick-NBKCoreKit.podspec,Numberick-NBKDoubleWidthKit.podspec\}

[ypopovych]

You have to lint all of them one by one. Start from the core one and add one dependency at a time. You can share the env variable through the $GITHUB_ENV file, and append one more podspec after each successful lint

[ypopovych]

And update the version by regex from a tag name. It really works better. Because you can forget to update podspecs before creating a tag and it will break everything. It's better to do less work. That is simply from practice

[oscbyspro]

I see you're saying, but not why it's needed. In my mind, "lib lint Numberick.podspec" covers all of them, no? It runs every test in the package, and it can only do so if "Numberick-NBKCoreKit.podspec" and "Numberick-NBKDoubleWidthKit.podspec" are valid specifications, no?

[oscbyspro]

Re: regex. There's a problem of "If you change the thing you're testing, how do you know the unchanged version is valid?" correctness-headache that I'd like to avoid if at all possible.

[ypopovych]

I see you're saying, but not why it's needed. In my mind, "lib lint Numberick.podspec" covers all of them, no? It runs every test in the package, and it can only do so if "Numberick-NBKCoreKit.podspec" and "Numberick-NBKDoubleWidthKit.podspec" are valid specifications, no?

No. It will run only tests from Numberick.podspec and will ignore other package tests. You can specify all tests inside Numberick.podspec only, but it breaks the idea of modules. So if you want to run tests from Numberick-NBKCoreKit.podspec you have to lint it too. Specify package tests in package podspecs and lint them all one by one

[ypopovych]

Re: regex. There's a problem of "If you change the thing you're testing, how do you know the unchanged version is valid?" correctness-headache that I'd like to avoid if at all possible.

In the case of CocoaPods, it's ok because before publishing it will test the exact version you are publishing. So it will be tested after the version update and published only if everything works fine. And for the test workflow, you don't need to change anything. Use version 999.99.9 and it will work with it just fine

[ypopovych]

I see you're saying, but not why it's needed. In my mind, "lib lint Numberick.podspec" covers all of them, no? It runs every test in the package, and it can only do so if "Numberick-NBKCoreKit.podspec" and "Numberick-NBKDoubleWidthKit.podspec" are valid specifications, no?

I prefer to do something like this: main...ypopovych:Numberick:pods-lint

so it will not break the module structure of the library (tests will run for proper modules, not from Numberick)

[oscbyspro]

so it will not break the module structure of the library (tests will run for proper modules, not from Numberick)

Sounds reasonable to me. I'm contemplating what to do with tags and such. I kinda want to validate things before I tag them. I'm unsure whether there's a great way to automate pre-tag validation beyond a script with manual dispatch, however.

[ypopovych]

so it will not break the module structure of the library (tests will run for proper modules, not from Numberick)

Sounds reasonable to me. I'm contemplating what to do with tags and such. I kinda want to validate things before I tag them, y'know. I don't know if there's a great way to automate it beyond a script with manual dispatch, however.

I thought of 2 solutions for my repositories:

1. Draft the release and then update it to full release. Do a draft release, it will run all tests automatically and if everything is ok, set it to full release and it will run deploy scripts (need a proper "on" triggers).
2. Special action which can be run manually, and will do a release from it through gh CLI. Run it from the main branch, path 3 parameters - version, name, and full description, and it will test everything if tests passed - will publish the release and trigger publish action for it. More automatic way than the first one, but needs more work.

[oscbyspro]

I thought CocoaPods publishing was set to manual dispatch and got excited about pressing the button on v0.11.0. But, apparently, it triggers on release and v0.10.0 was published. So, does it work? I haven't tried it.