Allow plugins not to support macOS

With the federated model, adding a macos platform to a frontend plugin pubspec.yaml results in a failure. This line detects there's a macos plugin, and expects a macos. The work around solution is to add a macos folder with a no-op podspec, just as we are doing for iOS on macos plugins.

This is the error I get when flutter run -d macos on url_launcher (WIP)

CocoaPods' output:
↳
      Preparing

    Analyzing dependencies

    Inspecting targets to integrate
      Using `ARCHS` setting to build architectures of target `Pods-Runner`: (``)

    Fetching external sources
    -> Fetching podspec for `FlutterMacOS` from `Flutter/ephemeral/.symlinks/flutter/darwin-x64`
    -> Fetching podspec for `url_launcher` from `Flutter/ephemeral/.symlinks/plugins/url_launcher/macos`
    [!] No podspec found for `url_launcher` in `Flutter/ephemeral/.symlinks/plugins/url_launcher/macos`

Pubspec looks like this:

flutter:
  plugin:
    platforms:
      android:
        package: io.flutter.plugins.urllauncher
        pluginClass: UrlLauncherPlugin
      ios:
        pluginClass: FLTURLLauncherPlugin
      web:
        default_package: url_launcher_web
      macos:
        default_package: url_launcher_macos

That line is a hack that's supposed to be replaced with platform-specific plugin files per platform (see discussion in iOS/Android bugs).

I would much rather we just finally fix that rather than continuing to layer hacks into all the plugins.

Note that I had a WIP PR for adding platform-specific plugin files linked from another bug, IIRC the iOS one. It can be adopted incrementally (e.g., switch just macOS to using it first, then other platforms later).

I was continuing your WIP work on creating a .flutter-plugins file for each platform, but the tools team wants to make a more comprehensive plan on how this should work. They suggested we leave this as it is for now, and reassess once they come up with the plan.

Okay. I'm a bit confused since I thought per-platform files was the comprehensive plan...

@blasten

As I understand it, there is a similar problem with android when building with android studio, so the team wants to think about it at a higher level. @blasten might be able to explain better :)

The issue with iOS iirc is that the plug-in file parsing logic is in the users podfile, not in tree so we can't update it cleanly

there is a similar problem with android

Yes, and with iOS as well, which is why the proposal was to move to having a separate plugins file list for each platform.

The issue with iOS iirc is that the plug-in file parsing logic is in the users podfile, not in tree so we can't update it cleanly

Unless we want to require stub implementations in every plugin forever, I don't see how we can avoid addressing that in any solution though, either by requiring manual updates by users (which for many people would just mean deleting the file so that it would be recreated), or writing some kind of migration logic.

@jonahwilliams

The concern was to avoid working on something that might be reworked soon. Changing the location of .flutter-plugins and flutter-plugins-dependencies is non-trivial change. We would have to modify the way settings.gradle file is generated, which is a breaking change. There were also issues with AS generating the gradle config differently from what the tool does.
I agree that at some point we'll need to do that anyway or have some migration logic, but I believe the team wanted to have a better plan for it and address all these stub implementation issues in a more correct way.

That said, I did get something working for all platforms, leaving the files location untouched for android. It's not a huge change and it might be better than having the ios/macos stub implementations so it might be worth taking a look.
Here's the PR, working on tests still:
#47258

If people think this is worth continuing then I'm happy to finish
@jonahwilliams @blasten @amirh

@jonahwilliams

Followed up with @jonahwilliams offline yesterday. I'll continue working on this.

@franciscojma86

#39657 (comment)

The JSON logic has already landed. The migration part will be discussed here , which might depend on the decisions taken in this proposal

Same question here, @franciscojma86: can this issue be closed? Or is there more work to track here?

We should update macOS to share the utility added in #45197, and follow the same migration process iOS is doing.

[battery_plus] Add dummy .podspec for macOS

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Allow plugins not to support macOS #46618

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow plugins not to support macOS #46618

Description

Activity

franciscojma86 commented on Dec 9, 2019

franciscojma86 commented on Dec 9, 2019

stuartmorgan-g commented on Dec 9, 2019

stuartmorgan-g commented on Dec 9, 2019

franciscojma86 commented on Dec 17, 2019

stuartmorgan-g commented on Dec 17, 2019

franciscojma86 commented on Dec 17, 2019

jonahwilliams commented on Dec 17, 2019

stuartmorgan-g commented on Dec 17, 2019

franciscojma86 commented on Dec 18, 2019

franciscojma86 commented on Dec 20, 2019

jmagman commented on Jan 21, 2020

stuartmorgan-g commented on Jun 10, 2020

github-actions commented on Aug 8, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions