Flutter and non-flutter dependency conflict with "platforms" pubspec key

[vaind]

Environment

• pub version or flutter pub version: Pub 2.8.4
• OS version: Linux 5.4
• Are you using the Chinese community mirror or a corporate firewall? no

Problem

I'm maintaining a package that supports both "plain" dart native and flutter (ios, android) and wanted to update pubspec to the new format including "platforms".

After adding platforms key to the pubspec.yaml, pub publish prints the following error (see this PR #2265):

Package validation found the following error:
* pubspec.yaml allows Flutter SDK version 1.9.x, which does not support the flutter.plugin.platforms key.
  Please consider increasing the Flutter SDK requirement to ^1.10.0 (environment.sdk.flutter)

OK, so I add flutter to the environment and pub publish works now:

environment:
  sdk: ">=2.6.0 <3.0.0"
  flutter: ">=1.12.0 <2.0.0"

But this change has dropped the non-flutter (plain dart) support so dart-only packages depending on this lib are broken:

$ pub get
Resolving dependencies... 
Because dart_only_app depends on objectbox_flutter_libs from path which requires the Flutter SDK, version solving failed.

Flutter users should run `flutter pub get` instead of `pub get`.

Proposed solution

Change the pub publish error to warning so the package with the platforms key can be publish even if it doesn't specify the dependency on flutter explicitly.

[jonasfj]

I have the same problem with package:webcrypto, and I kind of knew #2265 would cause this problem for a few packages.

We don't really support distributing "Dart plugins" on pub.dev, the way we have support for "Flutter plugins".
IMO, the long-term solution is that we need to define what a "Dart plugin" is, the same way we have "Flutter plugins".
But this might take a while..

In the mean time, it possible to distribute packages on pub.dev that uses dart:ffi and requires users to do some manual setup steps. This effectively what you have been doing in objectbox-dart, I'm guessing that's your repository?

I suppose it is possible to publish two versions of the package with different pubspecs... Something like:
0.1.0 for flutter, and 0.1.0-dart for dart. I'm not sure this is a good idea, just yet :D

---

I'm not sure it's wise to allow publishing flutter plugins that doesn't have an SDK constraint on Flutter. The fact that this was possible in the past was probably a bug.

[jonasfj]

Two versions might be a bit unwise... Because an incompatible flutter version would then pick the pure-Dart version that doesn't work for it.

It's probably better to make two packages objectbox-dart and objectbox-flutter, you could then make objectbox-ffi that contains all the shared logic... and all the -dart/-flutter variants does is supply DynamicLibrary somehow..

The downside is that downstream packages will have to pick which of your two packages they target.

[vaind]

@jonasfj thanks, those are the options we were discussing as well, or alternatively, having just a objectbox_flutter_libs (a flutter plugin just with the libs) the flutter users would have to depend on in addition to objectbox. We don't really like the idea of having multiple packages on pub.dev too much tough...

[jonasfj]

alternatively, having just a objectbox_flutter_libs (a flutter plugin just with the libs) the flutter users would have to depend on in addition to objectbox

That sounds like a good solution.

We don't really like the idea of having multiple packages on pub.dev too much tough...

Me neither... long-term we'll have to come up with a proper solution for "Dart plugins", so that these just work on Flutter and Dart.

[greenrobot]

We don't really support distributing "Dart plugins"

The ironic thing is that we don't need "plugins". We are looking into plugins only as a workaround for a change introduced in Flutter 1.20. I think what we really try to do is something like a "platform aware Dart package". We provide native libraries (currently Android and iOS and will do Windows, Linux, macOS later), which are used from Dart directly. As we have no use for plugins, we provide dummy implementations to make Flutter happy (iOS lib is not picked up otherwise).

[jonasfj]

We provide native libraries (currently Android and iOS and will do Windows, Linux, macOS later), which are used from Dart directly.

Oh, so you provide native binaries? You don't ship source as part of the plugin?

[vaind]

Oh, so you provide native binaries? You don't ship source as part of the plugin?

Yes, https://pub.dev/packages/objectbox creates a dart wrapper around the native objectbox-c library

https://pub.dev/packages/objectbox depends on http://github.com/objectbox/objectbox-c which is provided as a native library (.so/.dylib/.framework/.dll binary lib) + headers. For iOS and Android, we take the built objectbox-c binary library artifact from objectbox-swift and objectbox-java projects respectively - just because those projects use the same lib as well and already have the builds for the target platforms in place.

[sigurdm]

@jonasfj can we close this in favor of #3693 ?

[sigurdm]

Closing in favor of #3693.