[Bug] Optionally disable remote-checking in `scoop status`

[twirlse]

Current Behavior

scoop status takes ~3 times more time in v0.2.3 vs v.0.2.2

Additional context/output

scoop status in v0.2.3

scoop status in v0.2.2

top functions

Possible Solution

It seems that in 0.2.3 Test-UpdateStatus is run for each bucket which is quite expensive.

System details

windows 11 (21H2 build 22000.778)
x64
ps core: 7.2.5
git version 2.37.0.windows.1

Scoop Configuration

{
  "lastupdate": "2022-07-12T16:41:04.1824139+02:00",
  "SCOOP_REPO": "https://github.com/lukesampson/scoop",
  "SCOOP_BRANCH": "master",
  "shim": "kiennq",
  "aria2-warning-enabled": false
}

[rashil2000]

This is to be expected. Previously there was a bug/missing feature in scoop status where it did not tell the status of buckets.

Now it does.

[twirlse]

I understand the rationale behind the change, however in my opinion this is a major degradation in performance. Perhaps it is possible to run those tests in parallel or to find some other solution?

Disclaimer: I understand that this is a subjective opinion and that different people have different workflows.

I wonder how often you are running status without running update first?
I personally don't really care about outdated buckets check in scoop status because I will always run scoop update first, and than scoop status (multiple times) in order to see what should be updated.

I thinks there should be a distinction in what is assumed for different scoop commands (local vs remote status).

I personally don't expect scoop status to check remote status for buckets.
Neither do I except scoop status to show me that there is a new scoop version.
That is because there is no way (as far as I know) to rollback to previous scoop version or get latest buckets without updating scoop. So I just let scoop do it thing when I run scoop update.

For me it'll be best to just remind a user to run scoop update before scoop status (if there are no faster solutions for remote status check) because it what I do naturally.

[rashil2000]

I understand the rationale behind the change, however in my opinion this is a major degradation in performance. Perhaps it is possible to run those tests in parallel or to find some other solution?

I wouldn't really call it a degradation as this was a feature addition. It was requested a long time ago and many maintainers (including me) felt the need to make scoop status fully comprehensive.

I wonder how often you are running status without running update first? I personally don't really care about outdated buckets check in scoop status because I will always run scoop update first, and than scoop status (multiple times) in order to see what should be updated.

Technically any subcommand of Scoop should be independent of any other; I understand your particular workflow but the decision to include a particular feature should not depend on what other subcommand has been run previously. Obviously we don't have any stats on what commands users run and when they run it (because Scoop does not collect any data).

I personally don't expect scoop status to check remote status for buckets. Neither do I except scoop status to show me that there is a new scoop version. That is because there is no way (as far as I know) to rollback to previous scoop version or get latest buckets without updating scoop. So I just let scoop do it thing when I run scoop update.

Removing those particular checks (by default) would be a breaking change for users.

---

Perhaps it would be best to explore alternative methods: such as parallel tasks as you said, or hide the remote checking behind some flag.

[aoisummer]

Perhaps it would be best to explore alternative methods: such as parallel tasks as you said, or hide the remote checking behind some flag.

Maybe provide an option like autoupdate: false to prevent this behavior before update app or check status?

In fact, this behavior will often lead to operation failure in some places with poor network quality, I mean ISPs in some places deliberately degrade the network quality to github.

[rashil2000]

In fact, this behavior will often lead to operation failure in some places with poor network quality, I mean ISPs in some places deliberately degrade the network quality to github.

No, the failure of remote-checking does not affect the core functionality of scoop status, i.e. telling the state of installed apps.

[aoisummer]

No, the failure of remote-checking does not affect the core functionality of scoop status, i.e. telling the state of installed apps.

But this will result in extremely long waits if multiple buckets are installed, even if these checks are using local buckets?

[goyalyashpal]

• How to stop scoop from auto-updating buckets? #3818