make the logic to locate the Flutter SDK more robust

[devoncarew]

When running pub get on a Flutter project, I see:

Resolving dependencies... 
Because mp_chart depends on flutter_test any from sdk which doesn't exist (the Flutter SDK is not available), version solving failed.

This is when using the pub client that is embedded in the flutter sdk (flutter/bin/cache/dart-sdk/bin/pub). Currently the pub client only locates the Flutter sdk when the FLUTTER_SDK environment variable is set. We should expand this to also check if the specific instance of the pub tool itself is part of the Flutter sdk (something like using Platform.resolvedExecutable, and verifying it's location).

[jakemac53]

Note that build_runner also needed to know if you were running from the flutter sdk or the dart sdk - you can check the Platform.version for the flutter string but only in newer versions.

We have an outstanding issue to have a fallback for older sdks that does some file system spelunking to figure it out.

It would be good to establish a common way of determining if you are running from the flutter sdk (and its location).

dart-lang/build#2528 is the issue for the build repo

[sigurdm]

I'd like to get a bit more context - what is the use-case of calling pub get directly for a Flutter project? Could you just use flutter pub get (or set FLUTTER_SDK manually)?

It is not clear to me that pub in flutter/bin/cache/dart-sdk/pub is publicly exposed, but is there to be embedded by the flutter tool, and the right way to get dependencies of a Flutter project is flutter pub get that would set FLUTTER_SDK correctly.

Personally I'd like to put as little flutter-specific logic in the pub client as possible. But I think it would make sense to give a better error message explaining to use flutter get instead.

[jakemac53]

It is not clear to me that pub in flutter/bin/cache/dart-sdk/pub is publicly exposed, but is there to be embedded by the flutter tool, and the right way to get dependencies of a Flutter project is flutter pub get that would set FLUTTER_SDK correctly.

It is easier if you are a flutter developer to not bother installing the dart sdk twice, and instead add the one from flutter to your PATH. I don't have an idea of how common it actually is though.

[devoncarew]

It is not clear to me that pub in flutter/bin/cache/dart-sdk/pub is publicly exposed

People do use the dart sdk embedded in the Flutter SDK, and @mit-mit has a proposal to make this an officially supported use case.

Given that a very large portion of dart usage happens in the context of Flutter, having pub understand when it's in the context of a flutter sdk makes sense to me. It's odd to see a "can't find the flutter sdk" error message from pub when it's being run from the flutter sdk.

[devoncarew]

It would be good to establish a common way of determining if you are running from the flutter sdk (and its location).

Yup, +1 to establishing a simple, common mechanism for this.

[sigurdm]

It is easier if you are a flutter developer to not bother installing the dart sdk twice, and instead add the one from flutter to your PATH. I don't have an idea of how common it actually is though.

If they are adding the dart sdk from Flutter to their path it will work perfectly for dart projects, and the flutter command will work for flutter projects.

Yup, +1 to establishing a simple, common mechanism for this.

If we have an easy way of doing this I would be fine with pub using that in addition to FLUTTER_SDK.

We would need both a way of knowing if we are run from a flutter sdk, and also a way of locating it.

It would be awesome if it was a general mechanism for finding any sdk - I suspect we will have the same issue for Fuschia but that might be too far fetched for first iteration.

[devoncarew]

If they are adding the dart sdk from Flutter to their path it will work perfectly for dart projects, and the flutter command will work for flutter projects.

The issue I ran into was that I had ~17 projects to run pub get for, and didn't know in advance whether they were regular dart projects or flutter projects.

If we have an easy way of doing this I would be fine with pub using that in addition to FLUTTER_SDK.

I think this would likely look something like using Platform.resolvedExecutable, looking up the right number of directories, and recognizing that we were running from the context of a Flutter SDK. The relative location of the Dart sdk has been stable for quite a while, and we can likely graduate it to API with some discussion.

Here's an example of the lookup logic:

https://github.com/flutter/devtools/pull/1555/files#diff-c647d3c72b91c3144d5b38e18a17433dR77

[jakemac53]

I think this would likely look something like using Platform.resolvedExecutable, looking up the right number of directories, and recognizing that we were running from the context of a Flutter SDK. The relative location of the Dart sdk has been stable for quite a while, and we can likely graduate it to API with some discussion.

Note that in bazel the Platform.resolvedExecutable has to be replaced with Platform.executable. This is because it is just a symlink in the bazel-bin directory, so resolving it gets you back to the source tree where there isn't a fully built sdk. The Platform.executable in bazel is I believe already a full absolute path to the runfiles dir (it is not invoked with just dart).

[sigurdm]

Here's an example of the lookup logic:

It would be nice to have a package for this - then the logic can change moving forward.

[sigurdm]

The issue I ran into was that I had ~17 projects to run pub get for, and didn't know in advance whether they were regular dart projects or flutter projects.

You could just set FLUTTER_SDK before running pub get.

[devoncarew]

You could just set FLUTTER_SDK before running pub get.

Yes, but users are not going to know to do that. I really think it's odd that the pub instance vendored into the Flutter sdk doesn't know how to locate the Flutter SDK.

[jakemac53]

Fwiw I think this behavior is pretty consistent with all binaries shipped with the sdk except maybe the analyzer. Granted, pub is a more user facing tool so it might make more sense for it to hardcode knowledge.

[natebosch]

I really think it's odd that the pub instance vendored into the Flutter sdk doesn't know how to locate the Flutter SDK.

If the flutter shipped version of pub wants to hardcode the knowledge about flutter it could do that in the shell script.

I think it would be sensible to search up for a flutter SDK on the principle that if we can figure out what the user meant to do, we may as well do it.

[jakemac53]

If the flutter shipped version of pub wants to hardcode the knowledge about flutter it could do that in the shell script.

We want to keep the Dart sdk that is shipped with flutter as close to the normal Dart sdk as possible, so I would like to avoid this if we can.

[sigurdm]

The issue I ran into was that I had ~17 projects to run pub get for, and didn't know in advance whether they were regular dart projects or flutter projects.

users are not going to know to do that.

Actually you could run flutter pub get in all the projects. That seems to work and requires no special knowledge.