Skip to content

Improved ASDF Support #5117

Closed
Closed

Description

@samdeane

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.

Activity

  1. added
    is enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.
    on May 24, 2024
  2. DanTup commented on May 24, 2024

    @DanTup
    Member

    The shim at ~/.asdf/shims/flutter is a one-line script which executes flutter via asdf.

    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/flutter binaries on PATH that 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.

  3. added
    awaiting infoRequires more information from the customer to progress
    on May 24, 2024
  4. samdeane commented on May 30, 2024

    @samdeane
    Author

    Could this be a symlink instead of a script?

    You'd have to ask the author of the asdf Flutter support.

    I'm not a fan of special-casing specific package managers

    Agreed. The solution I suggested (running flutter doctor -v and parsing the output) would work for any installation where the flutter executable was in the path.

  5. samdeane commented on May 30, 2024

    @samdeane
    Author

    Btw - if this is specifically for your own use, is there a reason not to just click the "Locate SDK" button

    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.

  6. DanTup commented on Jun 4, 2024

    @DanTup
    Member

    The solution I suggested (running flutter doctor -v and parsing the output) would work for any installation where the flutter executable was in the path.

    See my note above about this.. In the past, people have had Dart/Flutter binaries on PATH that were unrelated tools. flutter doctor can 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?

  7. samdeane commented on Jun 5, 2024

    @samdeane
    Author

    It seems like it might handle the issue without the drawbacks noted above?

    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.

    🤷

  8. samdeane commented on Jun 5, 2024

    @samdeane
    Author

    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.

  9. samdeane commented on Jun 5, 2024

    @samdeane
    Author

    In the meantime I have workarounds so it's not the end of the world - it would just remove a little bit of friction :)

  10. DanTup commented on Jun 5, 2024

    @DanTup
    Member

    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.json file in your project if we don't find it on PATH. 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.json before the one from PATH.

    Eg. if you have two SDKs:

    • /path/to/flutter1
    • /path/to/flutter2

    If you're using flutter2 in a project but have flutter1 on PATH, then when you open the project using flutter2 we should still use flutter2 for the workspace (including adding it to the PATH of any terminals spawned inside VS Code).

  11. github-actions commented on Jun 26, 2024

    @github-actions

    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.

  12. samdeane commented on Jun 27, 2024

    @samdeane
    Author

    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.json file in your project if we don't find it on PATH. 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.

    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 flutterRoot entry 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 xxx commands work fine from within the repo.

  13. DanTup commented on Jul 4, 2024

    @DanTup
    Member

    The repo is a mono which has a number of flutter apps and libraries in it. Looking at the main one, the flutterRoot entry in .dart_tool/package.config is pointing to the correct SDK path.

    Presumably this file is updated by Flutter?

    This is updated when you run pub get or flutter pub get.

    Just to confirm, are you seeing that:

    • The root flutter project references the flutter package from the correct SDK in its .dart_tool/package_config.json
    • VS Code is still prompting you to locate an SDK?

    If 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!

  14. github-actions commented on Jul 25, 2024

    @github-actions

    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.

  15. added this to the v3.104.0 milestone on Jan 21, 2025
  16. removed
    awaiting infoRequires more information from the customer to progress
    staleWill be closed soon if no response.
    on Jan 21, 2025
  17. DanTup commented on Jan 21, 2025

    @DanTup
    Member

    This should be improved by #5377

  18. reopened this on Jan 21, 2025
  19. DanTup commented on Jan 27, 2025

    @DanTup
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    is enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions