Support Swift Package Manager

[ShawnBaek]

Parse has two dependencies, Bolts and OCMock.

I think Bolts is not maintainability, so If we want to keep the Parse-Objc or support latest tech stacks like SPM, I think fork the Bolts is a better option.

Here is my suggestion.

1. Fork Bolts and OCMock into the parse-community.
2. Make a Package.swift for Bolts and OCMock to support SPM.
3. Make a Package.swift for Parse-SDK-iOS-OSX.

That's it.

What do you think about this?

Another option is to focus on the Parse-Swift like Parse Dart SDK.

PS. FireBase also has dependencies with OCMock. firebase/firebase-ios-sdk#3136

[drdaz]

Would we actually need to do anything to OCMock? It's not part of the distribution as far as I can tell; it's a development dependency.

FYI I don't know anything about SPM yet, but I assume it would be used to install the SDK to projects. Just using the SDK in a project doesn't require OCMock.

[mrmarcsmith]

This sounds like a great idea. Do you want to open a PR for the iOS part of the process?

[ShawnBaek]

@mrmarcsmith I can’t fork into the parse repository. (I’m not a member of Parse). So could you fork it? I’ll make a PR

[mrmarcsmith]

sure! It would be great if your PR included some instructions in the README on how to use SPM with Parse since this would be my first experience using SPM so I'm sure lots of other people are curious how to use it too.

[noobs2ninjas]

Anyone should be able to fork parse. Thats super weird.

So, I'm curious if we could talk to the bolts guys about just turning the repo to us. Like Parse, Bolts was previously maintained by Facebook and at around the same time as Parse they turned over Bolts to community contributors. So, theres probably at least a little report with them. Not to mention Parse is probably the largest application to use Bolts.

[ryang1428]

+1 to SPM support!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If you believe it should stay open, please let us know! As always, we encourage contributions, check out the Contributing Guide

[Vortec4800]

SPM is getting more popular recently and with WWDC and Xcode updates coming soon I'm guessing it will only increase.

Just bringing this up to see if we can re-open and figure out what to do with Bolts.

[TomWFox]

@noobs2ninjas has been communicating with FB open source so if someone wants to make a PR to bolts with SPM support we could probably get it merged now.

[paulfreeman]

Just to clarify, the PR is needed to Bolts-ObjC as the Swift version of Bolts is already SPM compatible.

[vdkdamian]

Any news on this topic?

[davidhakki]

Definitely bumping for support especially since now SwiftPM has a gui and has been updated to handle frameworks better. Its far easier and less cumbersome then pods at this point.

[asam139]

Please recently SPM is becoming more and more popular 🙏

[TomWFox]

We would gladly accept a PR for this, as I understand we still need SPM support from Bolts-obj.

[itayAmza]

Any progress with this one? tnx

[drdaz]

Right now I'm working on a fork of our dependency Bolts-Objc with SPM support. Once that works, I'll see if I can do the same to the SDK.

I can't give you an estimate on completion, sorry.

[drdaz]

I've got a PR open against Bolts that adds SPM support.

Started looking at this library today.

[drdaz]

WIP here

[funkenstrahlen]

Maybe not an option for everyone but there is a rebuild of the Parse API for iOS in Swift: https://github.com/parse-community/Parse-Swift

[carbonimax]

Any news ?

[drdaz]

There's nothing newer than what's on my branch right now that I'm aware of. But the main Parse SDK imports properly using SPM in that branch IIRC.

I do plan on getting it working, but I need to find time.

I'd welcome any help. PR is here.

[davidhakki]

Maybe not an option for everyone but there is a rebuild of the Parse API for iOS in Swift: https://github.com/parse-community/Parse-Swift

Problem is, its currently missing a lot of features and because they renamed a bunch of methods new users may struggle to implement it until documentation is updated accordingly.

[mman]

@mtrezza Exposing multiple .products from the same swift package is definitely possible and would probably work. The main issue for me is to keep the swift build and swift test always passing. And that was my concern where 3rd party dependency breaks the overall build & test. Let me dig into it a bit more (slowly)...

[drdaz]

When adding a package via SPM one can select which subpackages should be installed. Would that allow to add only the main Parse SDK without Facebook Utils and without the FB SDK as 3rd party dependency?

As @mman says, yes it should. I believe the only install route that suffers from everything always being installed is Carthage.

The main issue for me is to keep the swift build and swift test always passing. And that was my concern where 3rd party dependency breaks the overall build & test. Let me dig into it a bit more (slowly)...

It's a legitimate concern, but since we specify which version of the FBSDK we use, the breakage generally won't catch us unawares. Moving between FB dep versions is an explicit, conscious action, and the developer should be able to see if the update breaks anything.

The only place I see this causing issues is when an Apple SDK update breaks whatever version of the FB SDK we're using. And if that happens, it's likely to be because we're hanging on an old version; FB seems to keep up to speed with Apple's newest stuff pretty well. Even then, the move to a newer Apple SDK is a conscious move.

[drdaz]

@mman I've been bashing my head against something for a minute now... I've got my fork rebased with mainline, but it seems like no matter what I do, I can't get the tests to see the main source files. You're doing it with cSettings I gather, but when I do similar, they seem to be ignored.

Do you know of any reason why this might be? The only differences I can see are that I use the path and publicHeadersPath attributes.

EDIT: You've also flattened the source structure much more. Starting to think this might be the right way forward tbh.

[mman]

@drdaz Do you have any error messages?

The line: https://github.com/mman/Parse-SDK-iOS-OSX/blob/b1f2a5cd1e5df228c34171495af0ccd3455492a2/Package.swift#L25 here shows that tests must depend on Parse, Bolts, and OCMock, and we only use .headersSearchPath to actually lookup internal header files that are not public

[danipralea]

hello everyone. is there any kind of update on this?
I currently have a Package Resolution Failed error

[mman]

@danipralea What URL you specified as a dependency? I guess the way to the future is to use Parse Swift SDK implementation and fall back to this legacy repository only when you really need it and know what you are doing.

Feel free to use the spm branch of my fork from https://github.com/mman/Parse-SDK-iOS-OSX.git, that should resolve and work just fine but the question is whether this will ever get merged at all? CC @drdaz ?

[danipralea]

@mman yeah, I've already made the transition to Parse Swift SDK, but we still need to support this one as well. Big project, slow transition.

[mtrezza]

@mman Did you or do you want to open a PR for spm support?

@danipralea Please keep in mind the risks when using an unofficial fork of any Parse Platform repository that is outside of our GitHub org.

[mman]

@mtrezza I did a lot of temporary hacks to make the package compile for tvOS, macOS, and iOS, and it generally works, but I had to reorganize sources a lot (which I do not like), i had to #ifdef some stuff (which I do not like) so I am kind of neutral. It is not ready to be merged as is and requires more work, which I do not think is a time well spent given we want to move towards Swift implementation anyway... Let me think about it some more...

[mtrezza]

Got it. I think as long as this repo is embeddable with in some way, I think we're good. We made carthage work recently, so it's available I'd say.

[mtrezza]

Has there been any progress in adding SPM support? Would anyone be interested to pick this up?

The FB SDK is at 14.1.0 and we are still stuck at 11.0.1, because they have deprecated support for carthage in favor of SPM. Upgrading the SDK could help developers who are not ready to migrate to the Parse Swift SDK. The migration process is also not documented yet, so this gives a bit more time. We could also increase the bounty if necessary.

[mtrezza]

@mman Could you open a PR from your spm branch to this repo, so others can see the diffs and build upon it?

[mman]

@mtrezza Sure, I have opened parse-community/Bolts-ObjC#3 and #1659.

[mtrezza]

Thanks, if you find some time, could you resolve the conflicts, so that these show the latest state compared to the target branches?

[mtrezza]

Hi everyone, @ricky641b will give it a shot to add full SPM support.

Luckily he can build on the PRs and investigations already done by you.

Let's support him with whatever questions he may have, to get this over the finish line - thanks especially to @mman, @drdaz!

[mman]

@ricky641b, @mtrezza I will be happy to help !!!

[mtrezza]

@ricky641b:

• cocoapods and carthage support can (or even should) be removed when implementing SPM. We are implementing SPM support the others actually don't work anymore in some scenarios. SPM solves this. Removing carthage & cocoapods should also make it easier for you to implement SPM, because it reduces the code base.

• The ParseFacebookUtils and ParseTwitterUtils can be removed from the SDK if they are an obstacle for SPM implementation. They are merely convenience wrappers for PFUser.linkWith(). But if they are kept, the SPM implementation must make it optional to install them, since not everyone may need it.

[mtrezza]

Could someone try out #1683 to add the SDK via Swift Package Manager?

cc @drdaz @mman

[ricky641b]

I can try it once again if you allow me to

On Thu, 5 Jan 2023 at 5:22 AM, Manuel ***@***.***> wrote: Could someone try out #1683 <#1683> to add the SDK via Swift Package Manager? cc @drdaz <https://github.com/drdaz> @mman <https://github.com/mman> — Reply to this email directly, view it on GitHub <#1453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSL4QIV774EBRJNMP7G2CTWQYEKXANCNFSM4IY5EKEQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Warm Regards *Bhavesh Gupta* Owner @ Atikin Technologies http://atikin.tech

[mtrezza]

@ricky641b The SPM integration should be done with #1683; with try out I meant to try to add the Parse Apple SDK via SPM in Xcode using the PR's branch.

[parseplatformorg]

🎉 This change has been released in version 2.0.0