pub icon indicating copy to clipboard operation
pub copied to clipboard

pub global activate via path not working unless `.dart_tool/pub/bin/<executable>` is deleted

Open btrautmann opened this issue 1 year ago • 11 comments

#### General info

- Dart 3.5.0 (stable) (Tue Jul 30 02:17:59 2024 -0700) on "macos_arm64"
- on macos / Version 14.7 (Build 23H124)
- locale is en-US

#### Project info

- sdk constraint: '^3.5.0'
- dependencies: 
- dev_dependencies: lints, test

#### Process info

|  Memory |  CPU | Elapsed time | Command line                                                                    |
| ------: | ---: | -----------: | ------------------------------------------------------------------------------- |
|   23 MB | 0.0% |     22:57:26 | dart devtools --machine --allow-embedding --dtd-uri ws:<path>/SLOui8f56EyIjsj7  |
| 2278 MB | 0.0% |     22:57:27 | dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.96.0 |
|  464 MB | 0.0% |        03:18 | dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.96.0 |
|   22 MB | 0.0% |     22:57:27 | dart tooling-daemon --machine                                                   |
|   82 MB | 0.0% |        03:18 | dart tooling-daemon --machine                                                   |
|   49 MB | 0.3% |     22:57:27 | flutter_tools.snapshot daemon                                                   |

The Issue

I started noticing a few weeks ago that dart pub global activate --source="path" <path> stopped working. To reproduce, you can:

  1. use a project created via dart create -t console <name>
  2. add the following to the pubspec.yaml
executables:
  name: name
  1. activate the executable globally via dart pub global activate --source="path" <path/to/root/of/project>
  2. Run the executable via name and note result
  3. Change the logic of the executable (in the case of the dart create -t console default project, update calculate() to return a different integer).
  4. Repeat step 3-4, noting that the result has not changed.
  5. Delete the .dart_tool/pub/bin/<name> directory
  6. Repeat steps 3-4, noting that the result does change this time.

Here is a sample repo you can clone and use to do the above.

Expected results

Prior to this bug, re-running dart pub global activate --source="path" would correctly update the activated executable such that the new logic would be respected.

btrautmann avatar Sep 24 '24 13:09 btrautmann

Summary: The user reports that dart pub global activate --source="path" no longer updates activated executables when the executable's logic is changed. Deleting the .dart_tool/pub/bin/<executable> directory before activating the executable again resolves the issue.

dart-github-bot avatar Sep 24 '24 13:09 dart-github-bot

Summary: The user reports that dart pub global activate --source="path" no longer updates activated executables when the executable's logic is changed. Deleting the .dart_tool/pub/bin/<executable> directory before activating the executable again resolves the issue.

Good bot

btrautmann avatar Sep 24 '24 13:09 btrautmann

@bkonyi can you LMK if this fell through the cracks? This is a pretty annoying bug to run into, particularly in cases like self-hosted github actions runners where state is not wiped between runs and so implementation hangs around until you remember this is a thing. I imagine there are others scratching their heads as to why pub global activate is not working. 👀

btrautmann avatar Oct 09 '24 19:10 btrautmann

Yeah, I'm not sure if the pub team is subscribed to the dart-cli-pub label, so I'll just cc @sigurdm and @jonasfj to make sure they're aware.

bkonyi avatar Oct 09 '24 19:10 bkonyi

Yeah - this is a bug. We are using snapshots, but we don't get to invalidate them (as dart run does).

sigurdm avatar Oct 11 '24 11:10 sigurdm

Perhaps best would be to have the binstub for a path-activated package just call dart path/to/package/bin/executable.dart instead of precompiling.

Alternatively the binstub needs to recompile (like we do in dart run).

sigurdm avatar Oct 11 '24 11:10 sigurdm

Yeah - this is a bug. We are using snapshots, but we don't get to invalidate them (as dart run does).

Just curious: This at one point did work the way I expected; did something change?

btrautmann avatar Oct 11 '24 13:10 btrautmann

A bisect shows it was introduced by a3ee209988af39c1d4f3c67b4910c317047356ca #3586

I can see that the claim "Always generate the full logic in the binstub (it will check for snapshot presence anyways)" is missing the point. There is no check if the code is updated relative to the snapshot.

sigurdm avatar Oct 11 '24 13:10 sigurdm

Sorry about that. We should probably revert to having the binstubs just invoke dart global run <dart-file>.dart instead of trying to use a snapshot.

sigurdm avatar Oct 11 '24 13:10 sigurdm

Is this a duplicate of https://github.com/dart-lang/pub/issues/4295? Or possibly the other way around.

I'm writing contribution guidelines and wanted to reference a single issue when suggesting a workaround.

SandPod avatar Jan 23 '25 13:01 SandPod

Ironically I ran into this while repro'ing another bug... Any idea when this might be able to be picked up?

btrautmann avatar Mar 13 '25 23:03 btrautmann

There’s another bug here. Even after you delete the snapshot, repeat steps 3–4, and obtain the updated results, running <name> still doesn’t behave as you expect. You’ll notice that now every time you run <name>, it rebuilds and runs, instead of using the new snapshot you just regenerated by deleting the old one. This happens because step 4 scrambles the snapshot path inside <name> (Actually, step 3 has no effect on regenerating the snapshot). However, if you run step 3 again, it will write the correct snapshot path back into <name>, and from then on, each execution of <name> works as all we expect.

javaddict avatar Jun 16 '25 10:06 javaddict