no "pub global update" command?

[iapicca]

Hi,
it's not a real issue, just a suggestion:
in need to update a package (webdev) I had to run
"pub global deactivate " and then "pub global activate ".

It's fine for a single package,
but what if you need to upgrade several packages?
Wouldn't be useful to have a "pub global update" command?
Also is a command that I sort of expected to find.

Thanks for reading, keep up the good job
Francesco

[jonasfj]

Please file this issue in the pub client, see:
https://github.com/dart-lang/pub

[kevmoo]

@jonasfj @iapicca – I did the transfer!

[bartekpacia]

I'm seconding this. I use many global Dart CLI tools. To name a few:

$ dart pub global list
mason_cli 0.1.0-dev.45
melos 2.9.0
patrol_cli 1.0.1+1
spec_cli 0.1.4

When I upgrade Flutter (and Dart with it), I have to manually activate each of these packages. Such a small feature, but would be great to have it!

[jonasfj]

@sigurdm, perhaps we should consider this use-case in some of thoughts we're trying to collect around dart run and friends.

[sigurdm]

Yes - indeed.

[SunlightBro]

I would like to work on this.

Is this feature still wanted by the dart team?
Are there any concerns/considerations that have to be evaluated first?

[jonasfj]

@sigurdm I don't mind an dart pub global update or dart pub global upgrade command.
What do you think?

---

@SunlightBro
The concern I have to with touching anything related to dart pub global is always PUB_CACHE, because:

• We want people to be able to reasonably switch between Dart SDK versions
  • Upgrading to new SDK
  • Downgrading to older SDK
• things stored in PUB_CACHE wrt. to dart pub global must be compatible (or recomputed across SDK versions).
• We must support all older PUB_CACHE layouts.

But if we can't do a dart pub global update command without changing the layout in PUB_CACHE, I don't see much harm.

---

Perhaps, we should debate if it's:

• dart pub global update, or,
• dart pub global upgrade, and,
• does it need to have an --all flag 🤣

I'm thinking we should probably aim to mirror behavior of dart pub upgrade.

So maybe it's:

dart pub global upgrade [[--all] | <packages...>]

Examples

• dart pub global upgrade --all, upgrade all globally installed packages
• dart pub global upgrade foo, upgrade only foo.
• dart pub global upgrade foo bar, upgrade foo and bar.
• dart pub global upgrade, print usage.

[SunlightBro]

Definitly get the concern about PUB_CACHE,
My thought was to also have something like

• dart pub global upgrade -n, --dry-run

that would list all packages that would be updated

[jonasfj]

@SunlightBro hmm, might I suggest you start by proposing what dart pub global upgrade --help should print.
After all, if you're going to do this, the help page has to be written anyways.
And the --help page effectively has to:

• enumerate all flags, and,
• explain what the command and flags do,

[SunlightBro]

Found some time to checkout the repo, and look into the flags of dart pub upgrade and dart pub global activate.

Any flag that I forgot?

~/pub -> master ✚ -> dart bin/pub.dart global upgrade --help 
Upgrade global packages to latest versions.

Usage: pub global upgrade [[--all] | packages...]
-h, --help              Print this usage information.
    --all               Upgrade all global installed packages
    --[no-]offline      Use cached packages instead of accessing the network.
-n, --dry-run           Report what packages would change but don't change any.
    --no-executables    Do not put executables on PATH.
-x, --executable        Executable(s) to place on PATH.

Run "pub help" to see global options.

I'm thinking we should probably aim to mirror behavior of dart pub upgrade.

pub upgrades --tighten and --major-versions don't make much sense for pub global upgrade, right?

Also I'm not sure if --no-executables and --executable are correct.

[jonasfj]

@SunlightBro

We could also try to draft the update that we'd need to do for:
https://dart.dev/tools/pub/cmd/pub-global

that way we further describe what the command will do, and how it'll work when options are combined.

pub upgrades --tighten and --major-versions don't make much sense for pub global upgrade, right?

Agreed, these make no sense.

Also I'm not sure if --no-executables and --executable are correct.

They certainly don't make any cases in combination with --all.

Can we detect the set of executables that was passed when a package was activated, because then it's those that we should re-activate when upgrading.

---

IMO, this looks good, we need to resolve what we want to do with --no-executables and --executable though.

@sigurdm thoughts?