Skip to content

flutter tool downloading Dart SDK twice #14700

Description

@tvolkert
$ flutter precache
$ diff -rq bin/cache/artifacts/engine/<platform>/dart-sdk bin/cache/dart-sdk

After #14610, those two SDKs are identical, yet we're still making the user download them both. That's ~116M of unnecessary download.

/cc @aam

Activity

  1. added
    toolAffects the "flutter" command-line tool. See also t: labels.
    a: first hourThe first hour of using Flutter
    on Feb 14, 2018
  2. self-assigned this
    on Feb 14, 2018
  3. devoncarew commented on Feb 14, 2018

    @devoncarew
    Contributor

    IDEs use the bin/cache/dart-sdk path; we'll need that to continue existing (or a migration plan for the IDE plugins).

  4. aam commented on Feb 14, 2018

    @aam
    Member

    The migration plan forward would be to use bin/cache/artifacts/engine/<linux-x64|darwin-x64|windows-x64>/dart-sdk instead of bin/cache/dart-sdk. Would that present a problem for IDE?

  5. tvolkert commented on Feb 14, 2018

    @tvolkert
    ContributorAuthor

    Alternatively, we could potentially explore symlinks, but I'm not sure whether whether we're ok with only supporting more recent versions of Windows that supports symlinks... Maybe we already do?
    @goderbauer

  6. devoncarew commented on Feb 14, 2018

    @devoncarew
    Contributor

    Symlinks (or copying files on platforms w/o useable symlinks) would work.

    The migration plan forward would be to use bin/cache/artifacts/engine/<linux-x64|darwin-x64|windows-x64>/dart-sdk

    I'd have a preference for a path that clients could use that didn't need to have detailed knowledge about how to construct the path (that wasn't different per OS and rely on the correct OS ids).

    bin/cache/dart-sdk is really pretty good from that perspective :) Keeping it would be great.

    In any case, heads up that tools are relying on the current path, and we'd want to have a migration plan and timeframe if we do decide to change.

  7. tvolkert commented on Feb 14, 2018

    @tvolkert
    ContributorAuthor

    Copying could work. The motivation for this bug is only to avoid a large download for the user.

  8. aam commented on Feb 14, 2018

    @aam
    Member

    I understand that introducing platform-sniffing code adds complexity into the tool, but creating symlinks or copying dart sdk puts increased cognitive load on the users(why there are two copies, if we end up copying which one is master, etc).

  9. aam commented on Feb 14, 2018

    @aam
    Member

    Of course we might have no choice but symlink/copy in case there is architectural problem with using platform-specific paths(like dependency_overrides section in flutter_tools/pubspec.yaml)

  10. tvolkert commented on Feb 14, 2018

    @tvolkert
    ContributorAuthor

    This could be a horrible idea, but another solution would be to have shell scripts that live in bin/cache/dart-sdk that call out to the platform-specific delegates.

  11. github-actions commented on Sep 3, 2021

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  12. locked as resolved and limited conversation to collaborators on Sep 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

a: first hourThe first hour of using FluttertoolAffects the "flutter" command-line tool. See also t: labels.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions