Repository navigation
Improved ASDF Support #5117
Copy link
Copy link
Closed
Labels
is enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.An enhancement or improvement that should be listed in release notes but is not a bug fix.
Milestone
Description
I have flutter/dart installed via asdf.
When I start VSCode, it sometimes fails to find flutter. Looking at the log, it appears to be finding the asdf shim, and then returning undefined because that shim is not actually in the SDK folder.
Here's an excerpt from the log:
[08:52:27] [General] [Info] /Users/sam/.asdf/shims
[08:52:27] [General] [Info] /Users/sam/.asdf/shims -> /Users/sam/.asdf/shims/bin
[08:52:27] [General] [Info] /Users/sam/.asdf/bin
[08:52:27] [General] [Info] /Users/sam/.mint/bin
[08:52:27] [General] [Info] /Users/sam/.local/bin
[08:52:27] [General] [Info] /opt/homebrew/bin
[08:52:27] [General] [Info] /Users/sam/Developer/Projects/mono/.bin
[08:52:27] [General] [Info] /Users/sam/Developer/Projects/mono/.bin -> /Users/sam/Developer/Projects/mono/.bin/bin
[08:52:27] [General] [Info] /usr/local/bin
[08:52:27] [General] [Info] /System/Cryptexes/App/usr/bin
[08:52:27] [General] [Info] /usr/bin
[08:52:27] [General] [Info] /bin
[08:52:27] [General] [Info] /usr/sbin
[08:52:27] [General] [Info] /sbin
... etc ...
[08:52:27] [General] [Info] Found at:
[08:52:27] [General] [Info] /Users/sam/.asdf/shims
[08:52:27] [General] [Info] Candidate paths to be post-filtered:
[08:52:27] [General] [Info] /Users/sam/.asdf/shims -> /Users/sam/.asdf
[08:52:27] [General] [Info] Returning SDK path undefined for flutter
The actual location of the flutter binary is ~/.asdf/installs/flutter/3.22.0-stable.
The shim at ~/.asdf/shims/flutter is a one-line script which executes flutter via asdf.
I realise that you probably won't want to special-case this, but it would be good if the method for detecting flutter's sdk could work in this scenario.
This could be achieved by using flutter doctor -v to obtain the actual location of the SDK.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
is enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.An enhancement or improvement that should be listed in release notes but is not a bug fix.
Activity
DanTup commentedon May 24, 2024
Could this be a symlink instead of a script?
I don't like the idea of executing a binary unless it looks like an SDK. We've had issues in the past with users having
dart/flutterbinaries onPATHthat are not SDKs (for example nodeJS packages!). We do already follow symlinks to then check if they look like an SDK and in order to support Snap and Hermit, we will back up and execute the original script first in case it needs to do some initialization (see 4bc199a).I'm not a fan of special-casing specific package managers because there are a number of (Snap, fvm, Hermit etc.) and it doesn't scale to individually support them (we did originally special case Snap, but then made that more generic because requests from other package managers came up).
Btw - if this is specifically for your own use, is there a reason not to just click the "Locate SDK" button when VS Code doesn't find the SDK and then navigate to the real SDK path? This will be persisted in your setting and you should not be asked again.
samdeane commentedon May 30, 2024
You'd have to ask the author of the asdf Flutter support.
Agreed. The solution I suggested (running
flutter doctor -vand parsing the output) would work for any installation where the flutter executable was in the path.samdeane commentedon May 30, 2024
It's a bit of an ugly solution, and it is brittle for updates of Flutter. If you are using anything (manual or automated) which keeps multiple versions of Flutter around, the VSCode setting will continue to refer to the old SDK, which could confuse things.
DanTup commentedon Jun 4, 2024
See my note above about this.. In the past, people have had Dart/Flutter binaries on
PATHthat were unrelated tools.flutter doctorcan also take a while to run, and we need the SDK search to be as fast as possible.I found this in the readme of asdf-flutter:
https://github.com/asdf-community/asdf-flutter?tab=readme-ov-file#vscode
It seems like it might handle the issue without the drawbacks noted above?
samdeane commentedon Jun 5, 2024
The problem is that setting a global env var rather defeats the point of asdf (which is that each project/workspace could be using a different flutter version), as does a global setting in vscode.
🤷
samdeane commentedon Jun 5, 2024
If one could persuade vscode itself (not your plugin) to evaluate
$(asdf where flutter)in the context of the loaded workspace, that would be fine. I don't think that's an option however.Unless one could somehow do the expansion in the workspace settings? I'm not sure what support vscode has for expansion whilst parsing the settings JSON files, but I suspect it's not that flexible.
samdeane commentedon Jun 5, 2024
In the meantime I have workarounds so it's not the end of the world - it would just remove a little bit of friction :)
DanTup commentedon Jun 5, 2024
Out of interest - in which cases are you hitting the issue where you're told the SDK is not found? For existing projects I would expect us to find your SDK via the
.dart_tool/package_config.jsonfile in your project if we don't find it onPATH. To get the "no SDK found" message suggests you don't have an SDK on PATH and we can't locate it from a project.If the issue only occurs when you create new projects (Eg. open VS Code without any project open, then try to run something like Flutter: New Project) then probably adding the latest Flutter version's real SDK to PATH will still solve your problem. We will still always take the SDK referenced by
package_config.jsonbefore the one fromPATH.Eg. if you have two SDKs:
/path/to/flutter1/path/to/flutter2If you're using
flutter2in a project but haveflutter1on PATH, then when you open the project usingflutter2we should still useflutter2for the workspace (including adding it to thePATHof any terminals spawned inside VS Code).github-actions commentedon Jun 26, 2024
This issue has been marked stale because it is tagged awaiting-info for 20 days with no activity. Remove the stale label or comment to prevent the issue being closed in 10 days.
samdeane commentedon Jun 27, 2024
I am getting it with an existing project.
The repo is a mono which has a number of flutter apps and libraries in it. Looking at the main one, the
flutterRootentry in .dart_tool/package.config is pointing to the correct SDK path.Presumably this file is updated by Flutter?
As mentioned above, the SDK itself isn't on path, but a shim to the flutter command is, and so
flutter xxxcommands work fine from within the repo.DanTup commentedon Jul 4, 2024
This is updated when you run
pub getorflutter pub get.Just to confirm, are you seeing that:
flutterpackage from the correct SDK in its.dart_tool/package_config.jsonIf so, could you reproduce the issue and provide more of the log where the SDK search occurs (you included a snippet above, but I'd like to see the entire set of paths where we look, as it should be reading from package_config too). You can email logs to [email protected] but ensure there's nothing sensitive in them.
Thanks!
github-actions commentedon Jul 25, 2024
This issue has been marked stale because it is tagged awaiting-info for 20 days with no activity. Remove the stale label or comment to prevent the issue being closed in 10 days.
DanTup commentedon Jan 21, 2025
This should be improved by #5377
Custom commands to obtain the Dart/Flutter SDK path (#5377)
DanTup commentedon Jan 27, 2025
Considered fixed by b1f79db. It's in the current pre-release extension and will be in the upcoming stable release (in the next week or so). If you find any problems using it, please open new issues with details.