SDK dependencies

[munificent]

We've been talking with the Flutter folks about how pub can gracefully support dependencies on packages that are physically located within the Flutter SDK itself. @nex3 and I have a proposal, and she has the details which she can do a better job explaining that I can.

Hopefully she will replace useless paragraph with said details. :)

[nex3]

First, we'll add explicit support for the Flutter SDK to pub. We want to do this in a way that leaves the door open for adding support for other SDKs in the future, but for the foreseeable future we expect to hard-code all such SDKs into pub—user-defined SDKs are a non-goal. We'll detect the presence and location of the Flutter SDK using an environment variable (e.g. FLUTTER_SDK_PATH).

SDK Constraints

Users will be able to specify constraints on the Flutter SDK's version similarly to how Dart SDK constraints are specified today:

environment:
  sdk: {flutter: "^1.2.3"}

A Flutter SDK constraint will fail if the Flutter SDK is not present, or if its version doesn't match the constraint. Users will be able to specify multiple SDK constraints:

environment:
  sdk:
    flutter: ^1.2.3
    dart: ^1.13.0

All SDK constraints must be satisfied in order for a package to be selected.

sdk Source

The heart of the plan is (re-)adding an sdk source. This will be an uncached, single-version source that provides packages from named SDKs. The SDK name is in the description. The user may include a version constraint, but (as for all single-version sources) this will only be used to accept or reject the single available version. SDK dependencies will look like this:

# If the current Flutter SDK includes cassowary 0.0.1, this will fail.
cassowary:
  sdk: flutter
  version: ^1.2.3

# This accepts any version of flutter_sprites that the SDK contains.
flutter_sprites: {sdk: flutter}

An SDK constraint will fail if the SDK name is unknown or unavailable, if the SDK doesn't have the given package, or if the SDK's version of that package doesn't match the given version. Determining which packages an SDK contains and where they're located will involve hard-coded, per-SDK logic.

SDK packages are expected to have pubspecs, which may have their own dependencies (some of which may also be SDK dependencies). These will be added to the transitive dependency graph when an SDK package is selected.

[munificent]

Do we need SDK constraints? It seems to me that the sdk source covers what it expresses already.

[nex3]

I think we do. SDK packages may have different version numbers than the core SDK, and there may by core SDK functionality that isn't represented by the packages it exports—for example, tool behavior. And if all the SDK packages do have the same version as the root SDK, it makes sense to have a central canonical constraint rather than repeating it across all SDK packages or just choosing one arbitrarily.

[nex3]

I've filed #1432 to track SDK constraints.

[nex3]

@sethladd @abarth I'm starting to poke around with this and I have a couple questions:

• Does the Flutter SDK have a version number? I can't find one, and when I run flutter --version it looks like it just emits the Git revision.
• What are the semantics of the packages' individual version numbers? It looks like they differ from package to package, but they don't seem to be consistently bumped when APIs change (see for example this CL).

[abarth]

Does the Flutter SDK have a version number?

Not yet, but we can add one.

What are the semantics of the packages' individual version numbers?

Currently they are larger than any version number of those packages that we've uploaded to pub.dartlang.org but otherwise don't have meaning.

We haven't invested much in version numbering because there wasn't any tooling to consume it. We can start investing more now that we're in the process of building that tooling. :)

[sethladd]

Just wanted to say thanks for this. We're giving it a shot.