Introduce `$FLUTTER_ROOT/sdk_packages.yaml`

[jonasfj]

trafficstars

When looking for sdk: flutter sdk-packages today, we do: https://github.com/dart-lang/pub/blob/98565c3e5defcd80c59910795ba3548552102f2c/lib/src/sdk/flutter.dart#L81-L95

Effectively, we search for <packageName> in (ordered by preferences):

• $FLUTTER_ROOT/packages/<packageName>
• $FLUTTER_ROOT/bin/cache/pkg/<packageName>

Instead of having multiple search paths hardcoded in pub, I propose that we introduce an sdk_packages.yaml file.

# Declaration of SDK-packages supplied by the Flutter SDK.
# An SDK-package is a package that the user can depend on
# using a dependency constraint like:
#
#         dependencies:
#           flutter_test:
#             sdk: flutter
#
# Paths in the list below are relative to this file.
sdk: flutter
packages:
- name: flutter
  path: packages/flutter
- name: flutter_test
  path: packages/flutter_test
- name: sky_engine
  path: bin/cache/pkg/sky_engine

Migration

1. dart pub will read sdk_packages.yaml when present, and fallback to existing logic when no sdk_packages.yaml file is present.
2. pub is rolled into the Dart SDK.
3. Flutter SDK starts supplying a sdk_packages.yaml file.
4. dart pub will refuse detect a valid Flutter SDK, unless sdk_packages.yaml is present.

Open questions

• We could bike-shed the name further, I'm open to ideas, sdk_packages.yaml just seemed natural.
• Should we use a .json file instead, it would arguably be a tiny bit faster, but we wouldn't be able to have comments.

---

@sigurdm, Do you agree that this would be cleaner from a pub perspective? And pretty easy to do?

@jonahwilliams, any thoughts? is there anyone else you think we should run this past?

@christopherfujino, any thoughts? Is it intentional that flutter_tools is something that Flutter Apps can take a dependency on? If it doesn't have an API that you intend to expose, this could possibly offer a mechanism that would allow you to make it private.

Update: sdk-packages.yaml -> sdk_packages.yaml.

[dcharkes]

• We could bike-shed the name further, I'm open to ideas, sdk-packages.yaml just seemed natural.

🚲 🏠 Aren't underscores more common than dashes in file names in the Dart/Flutter ecosystem?

[christopherfujino]

@christopherfujino, any thoughts? Is it intentional that flutter_tools is something that Flutter Apps can take a dependency on? If it doesn't have an API that you intend to expose, this could possibly offer a mechanism that would allow you to make it private.

It's not intentional, espcially since it's not versioned I don't see how this would even do anything. If I'm understanding this proposal, simply by not providing a flutter_tools entry in sdk-packages.yaml would make it private? If so, SGTM.

Also, I agree with Daco that I would expect this to be sdk_packages.yaml, with an underscore.

[sigurdm]

@sigurdm, Do you agree that this would be cleaner from a pub perspective? And pretty easy to do?

Hmm - slightly cleaner maybe, but not really sure how much it would get us. I also worry ( that it would be slower. We have to read one more file, and parse the yaml (probably should be json) before opening a flutter package. This is probably not too bad, it is just another drop in the sea of indirections.

Could we not just move flutter_tools out of $FLUTTER_ROOT/packages/?

[jakemac53]

I think this would potentially be a good way to enable vendored packages in the Dart SDK, and also write a very general purpose test that no vendored packages have any pub packages in dependencies (only other vendored dependencies would be allowed for Dart vendored packages).

In particular for the macros package, moving that to a dart: library is turning out to be a lot more challenging that anticipated, and a vendored SDK package would both reflect more directly the kind of dependency that it is, as well as making it much easier to test, develop, and bootstrap.

[jakemac53]

@jonasfj would you be opposed to me playing around with just implementing this for the Dart SDK implementation in lib/src/sdk/dart.dart? I think it could be totally localized to that, and wouldn't have any implications for flutter, or any issues with releasing since it is purely a new feature.