SPM with custom module map #460

paulb777 · 2020-08-22T18:31:31Z

Alternative to #442. Fix #375

Add Swift Package Manager support via a custom module map
Adds tests to verify import syntax
Add a GitHub Action workflow to run the tests on PRs and pushes
Adds headers to the module map to support existing client usage. See SwiftPMTests/objc/objc-header.m.

I couldn't find another way to support client usage other than module syntax without adding the extra headers.
Without them would require source changes for existing clients as well as being problematic for testing libraries (versus frameworks) and Objective C++ that doesn't support module imports.

Any suggestions about a better way?

erikdoe · 2020-08-23T17:56:40Z

Maybe I misunderstand something, but weren't the modulemaps an approach to avoid the directory full of symlinks?

Also, OCMock uses Travis and not Githib Actions as CI system. In any case, given that the test is adding yet more complexity, I am happy not to have a test for the SPM file. There are no tests for CocoaPods and Carthage either.

paulb777 · 2020-08-23T18:41:22Z

One reason I added the tests is to make it clear the advantage of the extra directories. The extra directories make it easier for existing OCMock clients to migrate, since they can switch from CocoaPods to SPM without source changes. If there's only a module map, all clients will need to change their code to use the module import @import OCMock; to migrate.

So three questions:

Should file import support be deleted?
Should the tests move to travis?
Should the tests be deleted?

If the answer to all three is yes, the PR will be reduced to two files - the Package.swift and a module map.

twitterkb · 2020-08-24T17:43:37Z

just starting to catch up on the changes here w.r.t. SPM.

would like to see some solution that will allow us to start using OCMock as an SPM package …

i don't know which of the alternatives here is preferred at this point.

looking for a tl;dr on where the discussion on this is at and if there's a plan going forward.

erikdoe · 2020-08-24T18:20:13Z

As I have commented previously in various PRs, I'm not happy about adding a directory full of symlinks just for Swift PM. This PR has the additional issue that it introduces a new CI system (Github actions in addition to Travis).

We are making some progress and the questions asked by @paulb777 help. I would say that the benefit of easing migration from CocoaPods or Carthage to Swift PM is not worth the directory full of symlinks. Unless I'm missing something, that's a very niche use case. I assume that most clients that still use OCMock are mature Objective-C codebases grown over the years. What would be the reason for them to switch? Also, if a team makes such a major change then changing from #import to @import doesn't seem too much of a stretch.

I've seen the PR you opened, @twitterkb, and I've seen your comment, @paulb777. If the straight quotes aren't needed why did people seem to tell me that they are? Also, can someone please look at how modulemaps work in detail and come up with a proposal for Swift PM that requires neither straight quotes nor directories with symlinks?

In the meantime I'm going to look at the PRs flagged for 3.8 and some of the other bugfixes. It feels like we're going round in circles on this Swift PM topic. And it seems like it's a lot of work for a niche use case for which a workaround seems to exist, right?

twitterkb · 2020-08-24T18:53:31Z

We are making some progress and the questions asked by @paulb777 help. I would say that the benefit of easing migration from CocoaPods or Carthage to Swift PM is not worth the directory full of symlinks. Unless I'm missing something, that's a very niche use case. I assume that most clients that still use OCMock are mature Objective-C codebases grown over the years. What would be the reason for them to switch? Also, if a team makes such a major change then changing from #import to @import doesn't seem too much of a stretch.

in our codebase, we do indeed have a large and mature Objective-C codebase grown over 10 years … and we have committed (internally) to switching to use SPM for all code by WWDC 21 . we feel that in terms of dependency management that stays close to the Apple process, and w.r.t. inter-operability between Objective-C and Swift, Swift Package Manager based solutions are the way to go.

I've seen the PR you opened, @twitterkb, and I've seen your comment, @paulb777. If the straight quotes aren't needed why did people seem to tell me that they are? Also, can someone please look at how modulemaps work in detail and come up with a proposal for Swift PM that requires neither straight quotes nor directories with symlinks?

i don't know why you were told "straight quotes are the way to go". the pull-request i submitted is based on Apple's recommendation in the Issue Navigator when you open an existing project in Xcode12 for the first time … and this will allow us to replace a ruby script that we have used to enforce this behavior in all of our code (with OCMock being in an exclude-list from the ruby script). our solution for exposing the headers via SPM is a module.modulemap . i would have to investigate exactly what that might be for OCMock .

(the other pull-request i submitted is really somewhat independent of Swift Package Manager … it is related to being able to import OCMock in any kind of downstream module in a way that fulfills the modular header contract.)

In the meantime I'm going to look at the PRs flagged for 3.8 and some of the other bugfixes. It feels like we're going round in circles on this Swift PM topic. And it seems like it's a lot of work for a niche use case for which a workaround seems to exist, right?

use of Swift PM is definitely not niche in our case. it will be the focus of work by one of our teams for the 9 months or so following Apple's fall events.

paulb777 · 2020-08-24T19:28:07Z

I just push an update that removes the extra headers. It might be a good compromise.

With this module map, it's still possible for clients to do non-module imports with #import <OCMock/{header.h}, but #import <{header.h} no longer works. See the diffs in the tests from the previous commit for details.

I still want to do more testing on our source base.

twitterkb · 2020-08-24T19:37:13Z

Source/module.modulemap

@@ -0,0 +1,29 @@
+module OCMock {


in my experience, in many cases making this framework module OCMock is the canonical way of describing this to allow framework header or modular import. (though that is not what we did in the example i describe below of a legacy bit of code that we added module.modulemap support to …)

With framework module OCMock, I see:

$ swift test /Users/paulbeusterien/gh/ocmock/Source/module.modulemap:2:10: error: header 'OCMock/OCMock.h' not found header "OCMock/OCMock.h" ^ /Users/paulbeusterien/gh/ocmock/SwiftPMTests/objc/objc-module.m:1:9: fatal error: could not build module 'OCMock' @import OCMock; ~~~~~~~^~~~~~ 2 errors generated.

in that case, the header should possibly simply be

header "OCMock.h"

… however, it may also be the case that if you follow the guide of the other example i provided, framework may not be necessary.

Changing to header "OCMock.h" leads to fatal error: 'OCMock.h' file not found

It seems functional to add the wrapper scope like in the example, but I don't see what value it provides. I don't see any different functionality.

the wrapper scope in the example allows for submodule import, should that be desired.

we do perform submodule import of items in the example. when performing @import OCMock in our current code, we cannot perform submodule import, so have never done so. i don't think it's necessary, since nothing is really relying on it, and since for most use cases, it is test code, and worrying about eyeball complexity based on which submodules you are importing probably isn't as important. i can live without the submodule wrapper separation.

i am surprised that the header "OCMock/OCMock.h" syntax is fully required. that has not been something we have encountered in creating module.modulemap files.

if this works for the OCMock tests and works in modules you ingesting OCMock in, this feels like an appropriate start.

As I mentioned before I don't know Swift Package Manager. This exchange leaves me puzzled. Should it be framework, module, and/or header? Have you reached consensus?

Also, please bear in mind that I do not want to change the framework header. So, anything that requires double quotes or similar in OCMock's public header files is a non-starter.

twitterkb · 2020-08-24T19:43:29Z

Source/module.modulemap

@@ -0,0 +1,29 @@
+module OCMock {
+  umbrella header "OCMock/OCMock.h"
+  exclude header "OCMock/NSInvocation+OCMAdditions.h"


rather than having to include every existing .h as well as having to change this modulemap (and thus, technically, a small aspect of the API) every time the internal structure of OCMock changes in a way that causes the addition or deletion of headers, i would make this module.modulemap simply refer specifically to each header to be included.

that way, only when public headers get added or removed will this file also change … and the compiler will pretty quickly enforce such changes in the first thing that attempts to import the module.

possibly reference:

https://github.com/twitter/ios-twitter-logging-service/blob/master/Resources/module.modulemap

Commit coming that replaces the umbrella and excludes with a list of the public headers. Thanks!

twitterkb · 2020-08-24T21:38:31Z

Source/module.modulemap

@@ -0,0 +1,29 @@
+module OCMock {


the wrapper scope in the example allows for submodule import, should that be desired.

we do perform submodule import of items in the example. when performing @import OCMock in our current code, we cannot perform submodule import, so have never done so. i don't think it's necessary, since nothing is really relying on it, and since for most use cases, it is test code, and worrying about eyeball complexity based on which submodules you are importing probably isn't as important. i can live without the submodule wrapper separation.

i am surprised that the header "OCMock/OCMock.h" syntax is fully required. that has not been something we have encountered in creating module.modulemap files.

if this works for the OCMock tests and works in modules you ingesting OCMock in, this feels like an appropriate start.

paulb777 · 2020-08-25T00:10:07Z

Successful test on the Firebase repo at firebase/firebase-ios-sdk#6326

3a4oT · 2020-10-07T22:40:42Z

Can we merge this please?

paulb777 · 2020-11-02T23:36:38Z

Here's an update on the unsafeOptions issue:

SwiftPM allows unsafeOptions for dependencies specified by a commit hash. They're not allowed for versioned dependencies.

Thus, apps and libraries can still use OCMock for their internal testing, while usage of the libraries without the tests can still be versioned. Example at https://github.com/firebase/firebase-ios-sdk/pull/6860/files

mattsellars · 2021-03-12T22:56:59Z

Nice work here!

Is there anything else left that is preventing this from merging this? We would like to consume OCMock via SPM as soon as possible.

paulb777 · 2021-03-15T17:30:35Z

Firebase is using a fork https://github.com/firebase/firebase-ios-sdk/blob/master/Package.swift#L142. We won't promise to support this in the long term, but no plans to stop in the near term.

twitterkb · 2021-05-03T07:13:09Z

.github/workflows/spm.yml

+    steps:
+    - uses: actions/checkout@v2
+    - name: Xcode 12
+      run: sudo xcode-select -s /Applications/Xcode_12_beta.app/Contents/Developer


this no longer seems necessary …

@paulb777 , i don't know if adding spm.yml testing really is a complete non-starter. the only part that i thought was "unnecessary" was changing xcode-select to use the -beta .

fwiw, we are at the place where we need to move to SPM for OCMock for some changes we are making this week, and may be interested in going with your fork as a starting point, especially if it just works out of the box for us.

As I mentioned early on in this discussion (and repeated earlier today), OCMock uses Travis CI for continuous integration. Please do not add another CI system.

twitterkb

ping … would like to see if the community can agree on a canonical Package.swift file and move foward with this on master.

erikdoe · 2021-05-03T20:08:13Z

.github/workflows/spm.yml

+name: spm
+
+on:
+  push:
+  pull_request:
+
+jobs:
+  swift-build-run:
+    runs-on: macOS-latest
+    steps:
+    - uses: actions/checkout@v2
+    - name: Build
+      run: swift build
+    - name: Run
+      run: swift test


As I mentioned before OCMock uses Travis CI. Please do not add another CI system.

Does this PR become mergeable by moving the CI to Travis or are additional changes needed?

As I wrote last year, I'm okay with not having any tests for this. So, there isn't even a need to move this to Travis.

Regarding the status of the PR, there's still the open question around what should go into the .modulemap file. The discussion seemed to have petered out, which is why I asked for clarification earlier today.

If it can be merged, my preference would be to add the tests, to make it easier to maintain going forward. I'm fine to do that migration if you're ok with SPM tests in .travis.yml. The GHA tests run in a minute or two, so it should be minimal impact.

On the .modulemap discussion, since the current state has worked for us and others using the fork, my recommendation would be to keep it as is and address any shortfalls in another PR.

Okay, that means the .modulemap is good to go. If you want to add a test on CI, please don't add it directly to the Travis file. That only invokes make ci. So, the actual test should go into the makefile.

paulb777 · 2021-05-06T00:06:36Z

I rebased, did a small update, migrated CI to travis, and tested with Firebase in firebase/firebase-ios-sdk#8042

paulb777 mentioned this pull request Aug 22, 2020

Swift Package Manager #442

Closed

erikdoe mentioned this pull request Aug 24, 2020

CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER = YES_ERROR #461

Merged

twitterkb reviewed Aug 24, 2020

View reviewed changes

twitterkb approved these changes Aug 24, 2020

View reviewed changes

paulb777 mentioned this pull request Aug 24, 2020

Test OCMock SPM PR firebase/firebase-ios-sdk#6326

Closed

twitterkb reviewed May 3, 2021

View reviewed changes

erikdoe reviewed May 3, 2021

View reviewed changes

paulb777 added 5 commits May 5, 2021 13:40

SPM with custom module map

9d4f82b

Remove header links

91ecbaa

Public headers instead of umbrella and excludes

e88aae3

Xcode 12 is now GHA default

1224c98

Rebase, update Package.swift, and migrate CI to travis

adc9fce

paulb777 mentioned this pull request May 5, 2021

Migrate back to unforked OCMock for SPM firebase/firebase-ios-sdk#8042

Merged

paulb777 force-pushed the spm3 branch from 4ddaa1a to adc9fce Compare May 6, 2021 00:02

erikdoe merged commit b5d7b27 into erikdoe:master May 11, 2021

kainjow mentioned this pull request Jun 11, 2021

OCMock with Swift Package Manager Brightify/Cuckoo#335

Open

ajpallares mentioned this pull request Feb 15, 2022

OCMock with Swift Package Manager Brightify/Cuckoo#416

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SPM with custom module map #460

SPM with custom module map #460

paulb777 commented Aug 22, 2020

erikdoe commented Aug 23, 2020

paulb777 commented Aug 23, 2020

twitterkb commented Aug 24, 2020

erikdoe commented Aug 24, 2020 •

edited

Loading

twitterkb commented Aug 24, 2020

paulb777 commented Aug 24, 2020

twitterkb Aug 24, 2020

paulb777 Aug 24, 2020

twitterkb Aug 24, 2020

paulb777 Aug 24, 2020

twitterkb Aug 24, 2020

erikdoe May 3, 2021

twitterkb Aug 24, 2020

paulb777 Aug 24, 2020

twitterkb Aug 24, 2020

paulb777 commented Aug 25, 2020

3a4oT commented Oct 7, 2020

paulb777 commented Nov 2, 2020

mattsellars commented Mar 12, 2021

paulb777 commented Mar 15, 2021

twitterkb May 3, 2021

twitterkb May 3, 2021

erikdoe May 3, 2021

twitterkb left a comment

erikdoe May 3, 2021

paulb777 May 3, 2021

erikdoe May 3, 2021

paulb777 May 3, 2021

erikdoe May 5, 2021

paulb777 commented May 6, 2021

SPM with custom module map #460

SPM with custom module map #460

Conversation

paulb777 commented Aug 22, 2020

erikdoe commented Aug 23, 2020

paulb777 commented Aug 23, 2020

twitterkb commented Aug 24, 2020

erikdoe commented Aug 24, 2020 • edited Loading

twitterkb commented Aug 24, 2020

paulb777 commented Aug 24, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulb777 commented Aug 25, 2020

3a4oT commented Oct 7, 2020

paulb777 commented Nov 2, 2020

mattsellars commented Mar 12, 2021

paulb777 commented Mar 15, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

twitterkb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulb777 commented May 6, 2021

erikdoe commented Aug 24, 2020 •

edited

Loading