Skip to content

Migrate "pub get" to "dart pub get" #2944

Closed

Description

@jonasfj

The top-level pub command is scheduled for deprecation in favor of dart pub.

We added dart pub in version 2.10.0, so it might still be necessary to call pub get for some older versions of the Dart SDK.
However, we plan to insert a deprecation warning in the top-level pub command, in Dart 2.12.0 (next stable release of the Dart SDK). Hence, to avoid users experiencing a deprecation warning in pub get output, it would be preferable to migrate to dart pub get now.

See also: dart-lang/pub#2736

Activity

  1. added this to the v3.17.0 milestone on Nov 9, 2020
  2. added
    importantSomething important!
    in commandsRelates to commands (usually invoked from the command Palette)
    on Nov 9, 2020
  3. DanTup commented on Nov 9, 2020

    @DanTup
    Member

    @jonasfj will do! I presume it's fine to use "dart pub get" for both Flutter and non-Flutter projects? (right now we have to pick between pub get and flutter pub get to avoid an error when fetching for Flutter projects).

  4. jonasfj commented on Nov 9, 2020

    @jonasfj
    Author

    @DanTup I think it's best to use flutter pub get for flutter projects... It does some setup steps required for plugins and other things.

  5. DanTup commented on Nov 9, 2020

    @DanTup
    Member

    Got it - thanks! I wasn't sure if the reason for this change was to consolidate them both.

    BTW, I presume this applies to all pub commands (we also call pub upgrade, pub outdated, pub global list, pub global run)?

  6. jonasfj commented on Nov 9, 2020

    @jonasfj
    Author

    Yes, all pub commands should use dart pub :)

    There is also dart test now, for running tests.

  7. DanTup commented on Nov 10, 2020

    @DanTup
    Member

    There is also dart test now, for running tests.

    Currently we're running tests by running dart [pub snapshot path]. This is to get the same pause-on-start behaviour as when running non-tests on the VM (so we don't need to have separate code to handle this). This isn't ideal, but it seemed better than having to maintain separate code to handle this.

    We used to set DART_VM_OPTIONS=--pause_isolates_on_start=true but that had the issue of cascading to child processes too, which can mess up user tests that spawn Dart instances. There's a little discussion about that in dart-lang/pub#1018.

    So for now, unless you think there will be breakage, I'll leave the tests as-is but fix up the rest.

  8. added a commit that references this issue on Nov 10, 2020
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

    importantSomething important!in commandsRelates to commands (usually invoked from the command Palette)

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions