Skip to content
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

[google_sign_in_ios] Adds Swift Package Manager support #7356

Merged
merged 2 commits into from
Feb 12, 2025

Conversation

loic-sharma
Copy link
Member

@loic-sharma loic-sharma commented Aug 9, 2024

Adds Swift Package Manager support to google_sign_in_ios.

Fixes flutter/flutter#146904

Pre-launch Checklist

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@@ -26,17 +26,14 @@ end
require File.expand_path(File.join('packages', 'flutter_tools', 'bin', 'podhelper'), flutter_root)

# Suppress warnings from transitive dependencies that cause analysis to fail.
pod 'AppAuth', :inhibit_warnings => true
pod 'GTMAppAuth', :inhibit_warnings => true
inhibit_all_warnings!
Copy link
Member Author

@loic-sharma loic-sharma Aug 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous lines inhibited warnings but also added AppAuth and GTMAppAuth as CocoaPod dependencies:

pod 'AppAuth', :inhibit_warnings => true
pod 'GTMAppAuth', :inhibit_warnings => true

If the SwiftPM feature is enabled, this causes duplicate modules and the build fails.

name: "google_sign_in_ios",
platforms: [
.iOS("12.0"),
.macOS("10.15")
Copy link
Member Author

@loic-sharma loic-sharma Aug 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is bumped up to macOS 10.15. Required to depend on GoogleSignIn (here)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already require 10.15 (which is good, because otherwise this would be very hard to roll out in a non-disruptive way).

],
dependencies: [
// AppAuth and GTMSessionFetcher are GoogleSignIn transitive dependencies.
// Depend on versions which define modules.
Copy link
Member Author

@loic-sharma loic-sharma Aug 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This mirrors:

# AppAuth and GTMSessionFetcher are GoogleSignIn transitive dependencies.
# Depend on versions which defines modules.
s.dependency 'AppAuth', '>= 1.7.6'
s.dependency 'GTMSessionFetcher', '>= 3.4.0'
s.dependency 'GoogleSignIn', '~> 7.1'

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need this? Isn't not defining modules something that would only apply to CocoaPods, not SPM?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, let me fiddle with this

@loic-sharma loic-sharma force-pushed the spm_google_sign_in branch 7 times, most recently from f36566e to eb4c0d5 Compare August 9, 2024 22:34
@stuartmorgan
Copy link
Contributor

From triage: still blocked on upstream issues.

@loic-sharma
Copy link
Member Author

AppAuth-iOS 1.7.6 was released with the fix, this PR should be unblocked now: openid/AppAuth-iOS#871

@loic-sharma loic-sharma force-pushed the spm_google_sign_in branch 3 times, most recently from a11e7df to 687528d Compare November 26, 2024 20:45
@loic-sharma
Copy link
Member Author

This is failing xcode-analyze and native-test because our transitive dependency AppAuth has warnings, and we treat warnings as errors. This isn't a problem when using CocoaPods as we've configured it to ignore these warnings. Unfortunately, SwiftPM doesn't let suppress warnings in our dependencies.

Our options are to either allow packages to opt-out of warnings as errors, or, fix the warnings in the upstream dependency: openid/AppAuth-iOS#888

@stuartmorgan
Copy link
Contributor

stuartmorgan commented Dec 2, 2024

I'm okay with temporarily turning off warnings-as-errors for this package, but we should have a tracking issue with context for turning it back on.

Ideally we should also reference an SPM feature request for the ability to do what we used to do with Cocoapods. Having the ability to use different warning settings for code you control and code you don't is a fairly common feature in build systems.

@loic-sharma loic-sharma force-pushed the spm_google_sign_in branch 8 times, most recently from a25afdb to 8964482 Compare January 29, 2025 00:54
@loic-sharma loic-sharma force-pushed the spm_google_sign_in branch 2 times, most recently from 7eb402a to 77e6de9 Compare January 30, 2025 23:12
auto-submit bot pushed a commit that referenced this pull request Jan 31, 2025
Today, we treat Xcode warnings as errors on all iOS and macOS plugins.

However, the google_sign_in_ios plugin has dependencies with warnings. We're unable to suppress these warnings when using Swift Package Manager. As a workaround, we'll need to disable Xcode warnings for the google_sign_in_ios plugin. This will be done in a subsequent pull request (see #7356).

This change introduces `--xcode-warnings-exceptions` to the `native-test` command. When running Xcode test, `GCC_TREAT_WARNINGS_AS_ERRORS` will be provided only if the plugin isn't on the exception list.

Additionally, plugins that are the exception list are excluded from the `xcode-analyze` command.

Part of flutter/flutter#146904

# AppAuth and GTMSessionFetcher are GoogleSignIn transitive dependencies.
# Depend on versions which defines modules.
s.dependency 'AppAuth', '>= 1.7.4'
s.dependency 'AppAuth', '>= 1.7.6'
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fixes some but not all AppAuth-iOS warnings

@loic-sharma loic-sharma requested a review from vashworth February 4, 2025 23:49
@loic-sharma loic-sharma marked this pull request as ready for review February 4, 2025 23:49
@stuartmorgan
Copy link
Contributor

Ideally we should also reference an SPM feature request for the ability to do what we used to do with Cocoapods. Having the ability to use different warning settings for code you control and code you don't is a fairly common feature in build systems.

Did we find/file an issue for this that we can reference in the comments?

@vashworth
Copy link
Contributor

vashworth commented Feb 6, 2025

Ideally we should also reference an SPM feature request for the ability to do what we used to do with Cocoapods. Having the ability to use different warning settings for code you control and code you don't is a fairly common feature in build systems.

Did we find/file an issue for this that we can reference in the comments?

Looks like you can potentially use an unsafeFlag, however, "use of unsafe flags makes the products containing this target ineligible for use by other packages". I wonder if we could use it conditionally only during testing. @loic-sharma might be worth trying out. Perhaps using an environment variable?

https://stackoverflow.com/a/64842804

@stuartmorgan
Copy link
Contributor

It's not clear to me that that SO answer address our (and the questioner's) use case; it's showing suppressing warnings on a target being defined as part of the package, not on a dependency.

Either way though, "I want warnings in my code, but not in code I don't control" is a pretty standard thing to want, and a use case we have a demonstrated need for, so we should request SPM fully (not only via unsafe flags) support it.

@stuartmorgan
Copy link
Contributor

stuartmorgan commented Feb 6, 2025

To clarify, I don't consider this as blocking landing; if we do have a reference we can add, great, if not we can land without it but I think it's important that we (in parallel) provide feedback on ways that SPM doesn't work for us.

@loic-sharma
Copy link
Member Author

I did try various configurations of unsafeFlags, cSettings, swiftSettings to suppress dependency warnings. These worked locally on my machine. However, I could not get these suppressions to work in our CI. I was unable to reproduce locally, even if I used the same version of Xcode as our CI... It's not clear to me what's going wrong on our CI.

Copy link
Contributor

@vashworth vashworth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@loic-sharma loic-sharma added the autosubmit Merge PR when tree becomes green via auto submit App label Feb 12, 2025
@auto-submit auto-submit bot merged commit fd53793 into flutter:main Feb 12, 2025
77 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
autosubmit Merge PR when tree becomes green via auto submit App p: google_sign_in platform-ios platform-macos
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[google_sign_in_ios] Add Swift Package Manager compatibility to google_sign_in_ios
3 participants