Podspec missing in version 1.10.0

[egarni]

Describe the bug
Podspec missing in version 1.10.0.
Cocoapods is still widely used in the industry. Many other dependencies don't have SPM support, which makes it even harder if some others only support SPM..

To Reproduce
run pod install with version 1.10.0

Expected behavior
version 1.10.0 should support Cocoapods to prevent headaches. Please add the support back, we waited so long for the m1 fix 🙏

[Sherlouk]

I'm not sure this can be raised as a bug, the release notes explicitly state that CocoaPods support has been removed.

Deprecated: support for CocoaPods and Carthage has been deprecated. Please use the Swift Package Manager to depend on Snapshot Testing.

SPM and cocoapods can live side by side with little issues enabling a gradual transition. Do you have an explicit use case which prevents this?

[egarni]

You're probably right and this foes not fully qualify as a bug.
We would really prefer to not have to use several Swift dependency managers in parallel.
Is it really a lot of effort for you do continue the support of Cocoapods? Cocoapods is really far from dead and widely used by many companies, we would really appreciate if swift-snapshot-testing still had support for it.

[Sherlouk]

Functionality was removed in #637 under the goal of modernising the project - it seems to have been a rather intentional decision as the industry push is in the direction of SPM despite whether CocoaPods might have some legs in the short term.

It feels there is no technical reason why you can't still adopt this update but rather personal preference.

I'd definitely suggest updating the issue to reflect this - it's not a bug and communicating it as such can be confusing at best, harmful at worst.

As to whether support is added back it'd be one for @stephencelis to clarify intent on.

[stephencelis]

Is it really a lot of effort for you do continue the support of Cocoapods? Cocoapods is really far from dead and widely used by many companies, we would really appreciate if swift-snapshot-testing still had support for it.

Snapshot Testing was pretty much our only remaining project on CocoaPods, and we maintained support for it far longer than we expected to. While someone working with CocoaPods and Carthage regularly may have developed workflows to release things quickly, it was enough of a process that it really was a strain on each release. On the occasion that we had a new release, for SPM it's a matter of:

1. Push a new tag

For CocoaPods it was a matter of:

1. Install CocoaPods (if not installed)
2. Log into CocoaPods (not a straightforward feat when you need to track down login credentials, which I always have to do)
3. Update the podspec file
4. Figure out how to get pod validate to pass (not always easy and can break between CocoaPods releases), or figure out how to skip validation when pushing the spec
5. Figure out how to push the pod

At every step things can go wrong that can send a person down a rabbit hole for an hour or two.

Supporting Carthage on top of that included maintaining an Xcode project file in the repo for Carthage builds. We looked to use a code gen tool and config file to automate some of this, but that's just another build tool to keep track of and hope that it will continue to be supported in the future, and another config format to remember and learn as tool and Xcode updates are released. I think it's possible to also distribute binaries for Carthage, but I never could figure that out to be honest, and it'd be another build flow for us to maintain.

Finally, supporting CocoaPods and Carthage inevitable requires us being more than familiar with both tools to help triage associated issues that come in and help folks out with those issues. Neither of us use CocoaPods or Carthage anymore (we migrated to SPM a long time ago), so this ends up taking an inordinate amount of time. Both tools are impressive and have served us in the past, but we've personally moved on.

The Swift Package Manager comes with the language and has been integrated with the build tools for many years now, so we think that even if you use CocoaPods for some or even most of your dependencies, there's no real barrier to use both at once.

In the end we feel that our time would be better spent on the libraries themselves, so we've decided to deprecate library-level support for these tools.

I would like to note that if you do feel strongly about choosing and using CocoaPods for all your dependencies, you always have the ability to maintain your own custom podspec for Snapshot Testing. You may also want to suggest to the CocoaPods team a feature that adds SPM integration to the Podfile format.

We hope this sheds some light on the decision, which wasn't made hastily, and we hope you're able to migrate smoothly to SPM or a custom podspec.

[katzenbaer]

FWIW the release notes say

Deprecated: support for CocoaPods and Carthage has been deprecated. Please use the Swift Package Manager to depend on Snapshot Testing.

Removing support completely is not the same thing as deprecation.

In several fields, especially computing, deprecation is the discouragement of use of some terminology, feature, design, or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use.

[stephencelis]

@katzenbaer I've adjusted the language to be more pedantic. For what it's worth we didn't remove old CocoaPods/Carthage releases, so support is deprecated in some sense: we discourage use of CocoaPods and Carthage for SnapshotTesting because you won't get the most recent version.

[katzenbaer]

Thanks. The move makes sense but is disappointing as someone who was running a fork with the pixel-by-pixel differencing PR and looking to switch back to upstream for the perceptual differencing feature. Switching us over to SPM isn't trivial since we don't use it now and would need to do it through xcodegen.

[katzenbaer]

@stephencelis Actually, I'm trying to add the project now but am having issues because the package product has a different name than the package URL. And it results in a Missing package product 'swift-snapshot-testing' error on compilation.

Again, not blaming anyone on the decision here and I could definitely be doing something wrong, but it would have been nice to have a version or two heads-up for everyone to workout the migration quirks.

Edit: Managed to get it to work with xcodegen. For anyone else needing the same,

here's my top-level packages:

packages:
  SnapshotTesting:
    url: https://github.com/pointfreeco/swift-snapshot-testing.git
    minorVersion: 1.10.0

and inside a target:

    dependencies:
      - package: SnapshotTesting

[stephencelis]

@katzenbaer I’m not familiar with the latest config options of XcodeGen (another maintenance requirement of Carthage support), but the package name for 1.10.0 is swift-snapshot-testing. Does swapping that in for “package” help?

[iltercengiz]

I'm maintaining an SDK project in a large team and our main app project is still using CocoaPods (as well as all the teams contributing to the app). It's a bummer to see support being removed and I only realized this while checking the changelog of the latest release which has very good improvements and fixes that we needed in our SDK.

Although I understand the challenges of maintaining CocoaPods releases and the motivation to move away from it, maybe it could be grandfathered just by maintaining the pod spec file in the repo? So users can still utilize CocoaPods and fetch the framework by just mentioning the repo URL in Podfile.

Now I have to fork the repo, add the pod spec file and maintain it. I know I can use SPM alongside CocoaPods but in a larger team where we follow certain standards, it's not ideal. Any possibility to see the support coming back in a way that doesn't add too much burden to maintainers?

[mbrandonw]

Hi @iltercengiz, while it may be a bummer for you to maintain a fork of our repo, all things considered it also doesn't seem so bad. The downside to us maintaining the pod spec is that we don't use Cocoapods at all. That means we are likely to break Cocoapods with every release, creating frustration for everyone.

Also, I believe it is possible to maintain pod specs outside the library's repo. We have a few people do just that for our Composable Architecture library. If someone were to maintain a pod spec for snapshot testing we would happily link to it from the readme.

[iltercengiz]

Hey @mbrandonw , thanks for reply. As I said, I totally understand the rationale behind this decision. And it sounds like a good idea to maintain it outside the library too. I'll check and verify if we can follow the same approach or if I can finally pull the trigger and start a company wide transition to SPM. 😃 Love the work you guys put together, thank you.

[BoOelkers]

We are in the same boat as a lot of folks here as well. Working on an app that has a lot of Objc peppered throughout it so we cant migrate over to SPM just yet for the project. It does look like folks are working to get SPM supporting mixed targets very soon. Until then we'll continue to find a workaround. We are actually also on the fork that fixes the issues between M1 and Intel...