Skip to content

Conversation

@blasten
Copy link

@blasten blasten commented Jan 22, 2021

Tool side of #52267

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

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

@blasten blasten requested a review from jonahwilliams January 22, 2021 06:14
@flutter-dashboard flutter-dashboard bot added the tool Affects the "flutter" command-line tool. See also t: labels. label Jan 22, 2021
@google-cla google-cla bot added the cla: yes label Jan 22, 2021
@blasten
Copy link
Author

blasten commented Jan 22, 2021

@jonahwilliams what do you think of this approach? It supports hot-reload, etc... If it makes sense, I will still need to get the metadata from pubspec.yaml, which I don't think it's accessible at this point.

print('_registerPlugins is called');
}
void main() {
Copy link
Contributor

Choose a reason for hiding this comment

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

If you're going to generate a synthetic entrypoint, then I don't think you need the pragma or anything else special - just invoke _registerPlugins() before calling entrypoint.main.

Copy link
Author

Choose a reason for hiding this comment

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

main can be overridden by the embedding at runtime.

Copy link
Contributor

Choose a reason for hiding this comment

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

right :) . lots of moving parts here.

@jonahwilliams
Copy link
Contributor

IIRC this won't work as is without more changes in the resident_runner or the hot reload pipeline. The development compiler needs to be given the same entrypoint to compile as the app was built with - otherwise I don't believe hot reloads will work until a hot restart - and in this case that hot restart would blow away the plugin callback.

This will also require some special casing for g3, since they'll likely generate that file in a different way.

@blasten blasten requested a review from jonahwilliams January 25, 2021 19:05
Copy link
Contributor

@jonahwilliams jonahwilliams left a comment

Choose a reason for hiding this comment

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

Still looking at actual implementation, first comment is not to introduce more globals usage

Copy link
Contributor

@jonahwilliams jonahwilliams left a comment

Choose a reason for hiding this comment

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

General feedback: it is difficult to do a thorough review without tests, as I'm not quite sure what all of the expected changes are

@blasten blasten marked this pull request as ready for review January 26, 2021 01:59
@jmagman
Copy link
Member

jmagman commented Feb 18, 2021

Re: test failures

I added url_launcher: and url_launcher_macos: to a project pubspec. Before this change, .flutter-plugins-dependencies looks like:

  "plugins": {
    "ios": [
      {
        "name": "url_launcher",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "android": [
      {
        "name": "url_launcher",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "macos": [
      {
        "name": "url_launcher_macos",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "linux": [
      {
        "name": "url_launcher_linux",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "windows": [
      {
        "name": "url_launcher_windows",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "web": [
      {
        "name": "url_launcher_web",
        "path": "{path}",
        "dependencies": []
      }
    ]
  },

On this PR url_launcher is listed as a plugin for Windows, Linux, and macOS, with the platform-specific variant as a dependency.

  "plugins": {
    "ios": [
      {
        "name": "url_launcher",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "android": [
      {
        "name": "url_launcher",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "macos": [
      {
        "name": "url_launcher",
        "path": "{path}",
        "dependencies": [
          "url_launcher_macos"
        ]
      },
      {
        "name": "url_launcher_macos",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "linux": [
      {
        "name": "url_launcher",
        "path": "{path}",
        "dependencies": [
          "url_launcher_linux"
        ]
      },
      {
        "name": "url_launcher_linux",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "windows": [
      {
        "name": "url_launcher",
        "path": "{path}",
        "dependencies": [
          "url_launcher_windows"
        ]
      },
      {
        "name": "url_launcher_windows",
        "path": "{path}",
        "dependencies": []
      }
    ],
    "web": [
      {
        "name": "url_launcher_web",
        "path": "{path}",
        "dependencies": []
      }
    ]
  },

If that's the intended behavior of this PR, those tests should be updated.

@blasten
Copy link
Author

blasten commented Feb 18, 2021

Thanks @jmagman. That seems correct based on my changes. (which I had to review again :))

|| !podfileLockOutput.contains(':path: Flutter/ephemeral/.symlinks/plugins/url_launcher_macos/macos')
|| !podfileLockOutput.contains(':path: Flutter/ephemeral/.symlinks/plugins/test_plugin_swift/macos')
|| podfileLockOutput.contains('url_launcher/')) {
|| !podfileLockOutput.contains('url_launcher/')) {
Copy link
Member

Choose a reason for hiding this comment

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

The spirit of this check was to make sure the url_launcher framework was not embedded in the app. It was using the Podfile.lock as a shortcut for this. A more appropriate test now would be to validate that the generated app contains Contents/Frameworks/url_launcher_macos.framework but not Contents/Frameworks/url_launcher.framework.

Copy link
Author

Choose a reason for hiding this comment

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

got it. I added another check to the test for the time being. Do you have any suggestion about how to verify the frameworks?

Copy link
Member

Choose a reason for hiding this comment

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

Something like

  final String appDirectory = path.join(
    appPath,
    'build',
    'macos',
    'Build',
    'Products',
    'Release',
    '${path.basename(appPath)}.app',
  );

  final String frameworksDirectory = path.join(
    appDirectory,
    'Contents',
    'Frameworks',
  );

  checkDirectoryExists(path.join(
    frameworksDirectory,
    'url_launcher_macos.framework',
  ));

  checkDirectoryNotExists(path.join(
    frameworksDirectory,
    'url_launcher.framework',
  ));

There also may be a more appropriate test location for that check, like https://github.com/flutter/flutter/blob/master/packages/flutter_tools/test/integration.shard/macos_content_validation_test.dart

@fluttergithubbot
Copy link
Contributor

This pull request is not suitable for automatic merging in its current state.

  • The status or check suite Linux flutter_plugins has failed. Please fix the issues identified (or deflake) before re-applying this label.

@blasten blasten merged commit b7d4806 into flutter:master Feb 19, 2021
@blasten blasten deleted the tool_dart_plugin_registrant branch February 19, 2021 17:22
zanderso added a commit that referenced this pull request Mar 19, 2021
zanderso added a commit that referenced this pull request Mar 20, 2021
zanderso added a commit that referenced this pull request Mar 20, 2021
zanderso added a commit that referenced this pull request Mar 23, 2021
zanderso added a commit that referenced this pull request Mar 23, 2021
zanderso added a commit that referenced this pull request Mar 23, 2021
* Revert "Enable dart_plugin_registry_test (#76645)"

This reverts commit 109e0bb.

* Revert "Apply changes caused by #76662 (#77093)"

This reverts commit cdca648.

* Revert "Disable clang format in the plugin registrants (#76662)"

This reverts commit dadbd47.

* Revert "Disable warnings for the dart plugin registrant (#76561)"

This reverts commit 098ece5.

* Revert "Remove dart_plugin_registry_test timeouts (#76838)"

This reverts commit 1610a27.

* Revert "Implement dartPluginClass support for plugins (#74469)"

This reverts commit b7d4806.

Kick.
blasten pushed a commit to blasten/flutter that referenced this pull request Apr 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants