-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swift Package Manager #24
Swift Package Manager #24
Conversation
MaartenZonneveld
commented
Feb 5, 2024
•
edited
Loading
edited
- Add support for Swift Package Manager.
- Drop support for Carthage and Cocoapods.
Thanks for opening this PR @MaartenZonneveld. Any reason you closed this? Is this in favour of #23? |
Reopened now 👌 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CodeWise LGTM, alleen 2 stukjes code zijn commented... Mischien verwijderen of uncommenten? 🤔
Co-authored-by: Giordano Menegazzi <[email protected]>
@@ -1,4 +1,5 @@ | |||
import Foundation | |||
import MapboxCoreNavigationObjC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain why we sometimes use MapboxCoreNavigation and sometimes MapboxCoreNavigationObjC? Why the ObjC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Objective-C & Swift can not co-exist in a single swift package target. Therefore a separate target for the objective-C components is created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok got it. Would this mean, since we are in a swift file here, that we should rather import the swift dependency?
Sorry if this is a stupid question :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't matter if you import it from Objective-C or Swift. If this file uses something that is defined in the Objc package, it should import the Objc package.
platforms: [.iOS(.v14)], | ||
products: [ | ||
.library( | ||
name: "MapboxNavigation", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably we should rename this to MapLibreNavigation or something like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree we should rename it at some point. However, a rename like that would involve renaming a lot more parts of the repository. I think the scope of this PR should be limited to swift package manager, as it is already a big change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, if it's not just about the name here, but also refers to file names, then we can do this in a follow-up 👍
Package.swift
Outdated
let package = Package( | ||
name: "maplibre-navigation-ios", | ||
defaultLocalization: "en", | ||
platforms: [.iOS(.v14)], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is iOS 14 required for maplibre-native v6?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, MapboxDirections requires iOS 14 minimum
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a new requirement? I have seen that you added SPM support there as well, but I think the old Carthage build was compatible with iOS 8 or something like that.
Has something changed that much that requires iOS14?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The MapboxDirections fork supports back to iOS 12.0. So I now restored iOS 12 support for this PR as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for working on this. I can't comment about the SPM changes itself.
If we start with a fresh SPM package I think this should be released as MapLibre and not Mapbox.
The changes in CustomViewController.swift
seem to be unrelated to the SPM change. IMHO these should not be part of this PR to keep the commit history clean.
Is the use of Carthage and Cocoapods discouraged or why was it removed? Are the different types of integration incompatible? If not, I would be in favor of giving the user the choice. |
@mindthefish Swift Package Manager requires a certain structure, that is not compatible with how the project was structured before. With this PR it becomes structured for SPM, breaking the cocoapods and carthage integrations. It is of course possible to fix, and support all 3 integration solutions. However, that would encompass a lot more work, and tbh I don't believe cocoapods and carthage are worth the effort anymore. We could always bring back carthage and cocoapods support later if it is desired. |
f70598f
to
5c7e396
Compare
@MaartenZonneveld thanks for working on this. What is the state of this PR? Do you think we can get this merged soon? Currently CI is failing, that is something we should take care of before merging. |
Any update on this @MaartenZonneveld? I think this would be a great addition and I'd love to merge this. |
Currently using Maarten's fork in a new project we just started. It works. Would be important to merge it rather sooner than later, we'd like to do a few PRs against it to improve other things. |
I've been very busy with other projects. I hope to be able to work on it this week. If anyone has time to look into the failing CI, help is much appreciated 🙏 |
Thanks for the update @MaartenZonneveld. @hactar would you be able to look into the failing CI? I think this could speed up getting this PR merged. I would love to merge this PR as well. |
To review this PR, I took a closer look at the version of https://github.com/flitsmeister/mapbox-directions-swift referenced here. Attempting to check out, build and test it led to a bunch of problems that I cannot report in the repo because issues are disabled. |
@mindthefish you have opened So maplibre-navigation-ios Package.swift file references
We could update to
|
Our goal is to be independent of Mapbox dependencies, so we should not rely on it IMHO. We could decide to fork the directions repo and start a fresh fork, ideally in the MapLibre org. I am not sure if this will introduce other issues / changes. |
I've forked this branch and prepared a Pull Request to fix the CI. I've based my changes against @MaartenZonneveld fork and submitted a PR there, however no CI is running there. My second attempt was to submit the PR against this Repo in #33 however now I need a workflow approval from someone with write access. Now that there are 2 Pull Requests this might result in some confusion, so we should agree were we move forward (so I can close the redundant PR) and we get all feedback addressed in one place. |
I approved the workflow, thanks for working on this 👍. @MaartenZonneveld how would you like to progress? Should we go ahead and review/merge the PR from @Patrick-Kladek? Do you want to pull the relevant changes from #33? That said CI is currently failing for #33 |
@boldtrn thanks for approving, will check check why it fails |
So it turns out the build failed because the GitHub Actions macOS Image doesn't have the latest swift-tools version:
I've pushed the changes to fix this, however I need another approval. @boldtrn can you approve all my (future) runs or only grant access for one build at a time? |
I approved the CI again. Yeah, unfortunately an admin needs to approve the CI run until your first successful contribution to this repo. So for this PR I'll have to approve every CI run. If you want you can ping me in the OSMUS slack if you want to avoid writing here and if we need multiple runs. |
Just found out you can actually create multiple Pull Requests in different Repos from the same branch. Therefore I've created a PR in my fork, enabled GitHub Actions there and made it run. This was way faster and probably less annoying than to ping you every time. Here is the result: https://github.com/Patrick-Kladek/maplibre-navigation-ios/pull/1 My main finding for GitHub Actions are:
@boldtrn please approve the workflow again so we get a green checkmark there. After that we should decide how to proceed with reviewing this PR @MaartenZonneveld. |
Thanks a lot @Patrick-Kladek, the CI passed. @MaartenZonneveld please let us know how you would like to continue 👍 |
Great news, I can't wait to start using SPM for this repo. I'm still a little concerned that over 300 files have been changed to basically enable SPM, but I honestly don't have an overview of all those changes. |
@mindthefish I can comment only on my part of the changes, most of which are from deleted files like the Examples (I don't think we can support that via SPM) followed by moving files to different folders. I would guess the actual changes are 30-50 files and even there most were missing just some imports (seems like SPM is stricter here then Xcode, or Xcode adds some frameworks automatically) I would prefer to merge this rather sooner than later as this is a huge PR already. Afterwards I would prepare more Pull Requests like:
Once we have that we can make a new major release from where we will support SPM and are truly Maplibre without any references to Mapbox anymore |
Totally agree! |
Thanks again for providing this PR @MaartenZonneveld. Given that this is a big PR and kind of blocking further changes. Would you be able to provide some feedback on how we should continue with the two PRs until tomorrow? Are you fine with the changes from @Patrick-Kladek? Do you want to pull / cherry pick them in your PR or should we close #24 and go ahead with #33, or do you have a different idea? Given the importance, it would be great if we can go ahead with the SPM compatibility. |
As @MaartenZonneveld is not responding I would propose to continue the official discussion in PR #33 |
Given that there hasn't been any update here, let's close this PR in favor for #33. |