[FEAT] Improve the Method for Retrieving the Number of Applications Installed via Scoop and Winget

[SorYoshino]

Description

1. Currently, the number of applications installed via Scoop is often determined by reading the $ENV:SCOOP environment variable and counting the number of subfolders in the apps directory, excluding the scoop folder itself. I believe this method may originate from traditional installation habits, but Scoop’s official documentation no longer recommends this installation approach. This method depends on the presence of user-defined environment variables and does not cover globally installed applications.

When Scoop is first used to install any application, it appends <root_path>\shims and <global_path>\shims entries to the user's and system's Path environment variables, respectively. Therefore, a more flexible method would be to read the Path environment variable from the registry, identify entries that contain both scoop and shims, infer the root_path and global_path of Scoop, and then count the number of subfolders (excluding scoop itself) in each corresponding apps directory. This provides a more complete view of the applications installed via Scoop, both locally and globally.

Alternatively, sfsu list and sfsu list --global can also be used as complementary tools for application enumeration.

2. Regarding winget, I found a large number of related discussions in this project's issues. Please allow me to summarize and supplement them here.

The currently common method for obtaining the number of applications installed via Winget is by parsing the output of winget list. However, the results of this command actually include the following categories:

• a. Applications directly installed using winget install, which includes these entries;
• b. Applications not installed via winget install but still manageable by Winget—for example, some programs manually downloaded from the internet or installed through the Microsoft Store;
• c. Applications that cannot be managed by Winget, such as games installed via Steam, some Microsoft Store apps, or portable apps that do not write specific registry keys.

In principle, we should only count the first two categories, as these applications can be managed by winget. However, the second category may also include applications installed via other package managers. Due to the inherent characteristics of winget, this issue cannot be resolved. Furthermore, the output of winget list may include multiple versions or duplicate entries for the same application, which can introduce significant inaccuracies in the statistics.

winget sources are mainly divided into winget and msstore. The former will leave records under the directory:

$ENV:TEMP\WinGet\cache\V2_PVD\Microsoft.Winget.Source_8wekyb3d8bbwe\packages.

Specifically, applications installed using winget install will create subdirectories named after their application IDs within that folder. Additionally, running winget upgrade may allow applications in the second category above to leave entries there as well. Even if the user manually deletes a subdirectory, running winget upgrade will automatically recreate it, without duplication. It should be noted that uninstalling a Winget-managed application does not automatically remove its corresponding entry in that directory. As for apps installed from msstore, I have not yet found any useful records locally. Fortunately, these applications are generally only installable via winget; apps installed through other means will not be marked as originating from msstore.

In conclusion, rather than using winget list, which yields highly inaccurate results or may even fail to capture the application count, it is better to count the number of subdirectories under $ENV:TEMP\WinGet\cache\V2_PVD\Microsoft.Winget.Source_8wekyb3d8bbwe\packages as the basis. I'm not sure whether Winget will automatically clean up records of deleted applications in this folder after a certain period, but regardless of whether users manually clear this folder or not, the resulting error is still significantly lower than using winget list. I also believe that most users rarely install apps from the msstore source, so their impact on the statistical results is minimal—or we can simply clarify in the module description that the statistics do not include apps from msstore.

Motivation

The method for retrieving the number of installed applications using Scoop and Winget exists in the existing module, but the current method has some limitations or issues.

Although using Command Module meets my needs, integrating it as a native feature of Fastfetch into Fastfetch may be more convenient for users.

Additional context

Below is a test I conducted using sfsu with the following configuration:

{
    "$schema": "https://github.com/fastfetch-cli/fastfetch/raw/dev/doc/json_schema.json",
    "logo": {
        "type": "none"
    },
    "display": {
        "stat": true,
        "showErrors": true
    },
    "modules": [
        {
            "type": "command",
            "shell": "pwsh",
            "param": "-NoProfile -ExecutionPolicy Bypass -Command",
            "text": "& {(sfsu list).Count + (sfsu list --global).Count -2}",
            "key": "Packages"
        }
    ]
}

It is relatively fast to use sfsu to count the number from the output. So I think we can first check whether the user has installed sfsu. If so, we can call it directly. If not, we can read the registry.

┏[ Zertw from  ASUS][ 0s][ RAM: 11/15GB][ Sunday at 5:39:13 PM][]
┖[~]
└─Δ  fastfetch -c all --format json
[
  {
    "type": "Command",
    "result": "100",
    "stat": 767.3283000010997
  }
]
┏[ Zertw from  ASUS][ 0.836s][ RAM: 11/15GB][ Sunday at 5:39:30 PM][]
┖[~]
└─>  (scoop list).Count
Installed apps:
100

[CarterLi]

It should be noted that uninstalling a Winget-managed application does not automatically remove its corresponding entry in that directory.

Well, I don't think it's acceptable...

V2_PVD\Microsoft.Winget.Source_8wekyb3d8bbwe\packages
❯ ll | wc -l
76

V2_PVD\Microsoft.Winget.Source_8wekyb3d8bbwe\packages
❯ winget list | rg ' winget' | wc -l
50

The folder seems contain some packages that I never installed ( at least I don't know what they are, nor I can remember I installed some packages similar ). You can't explain to users what the result stands for.

[CarterLi]

[
  {
    "type": "Command",
    "result": "100",
    "stat": 767.3283000010997
  }
]

This is even much slower than the entire fastfetch command...

timeit { fastfetch -c none }
/////////////////  /////////////////    zhang@Carter-PC
/////////////////  /////////////////    ---------------
/////////////////  /////////////////    OS: Windows 11 专业版 x86_64
/////////////////  /////////////////    Host: 90V2000KCP (LEGION REN7000K-26IRB)
/////////////////  /////////////////    Kernel: WIN32_NT 10.0.26120.4741 (24H2)
/////////////////  /////////////////    Uptime: 1 day, 22 hours, 59 mins
/////////////////  /////////////////    Packages: 46 (scoop)
/////////////////  /////////////////    Shell: nushell 0.106.0
                                        Display (Odyssey G7): 3840x2160 @ 165 Hz (as 1920x1080) in 31" [External, HDR]
/////////////////  /////////////////    DE: Fluent
/////////////////  /////////////////    WM: Desktop Window Manager 10.0.26100.4741
/////////////////  /////////////////    WM Theme: Custom - Blue (System: Dark, Apps: Dark)
/////////////////  /////////////////    Icons: This PC, Recycle Bin
/////////////////  /////////////////    Font: Microsoft YaHei UI (12pt) [Caption / Menu / Message / Status]
/////////////////  /////////////////    Cursor: Windows 默认 (32px)
/////////////////  /////////////////    Terminal: Windows Terminal Preview 1.23.11752.0
/////////////////  /////////////////    Terminal Font: Maple Mono Normal NL NFMono CN (12pt)
                                        CPU: 13th Gen Intel(R) Core(TM) i7-13700KF (24) @ 5.40 GHz
                                        GPU: NVIDIA GeForce RTX 4070 Ti @ 3.10 GHz (11.71 GiB) [Discrete]
                                        Memory: 13.61 GiB / 47.73 GiB (29%)
                                        Swap: 35.67 MiB / 3.00 GiB (1%)
                                        Disk (C:\): 777.73 GiB / 952.72 GiB (82%) - NTFS
                                        Disk (D:\): 1.85 TiB / 3.68 TiB (50%) - NTFS
                                        Local IP (以太网): 192.168.1.13/24
                                        Locale: zh-CN



128ms 588µs

and I don't think I want to rely on a command that hasn't been accepted by scoop/main.

Therefore, a more flexible method would be to read the Path environment variable from the registry, identify entries that contain both scoop and shims, infer the root_path and global_path of Scoop, and then count the number of subfolders (excluding scoop itself) in each corresponding apps directory

This is acceptable.

[SorYoshino]

Well, I don't think it's acceptable...

However, compared to directly using winget list and winget list | rg ‘winget’, ll is not affected by duplicate applications or other applications that winget cannot manage, and it runs faster than them. The impact of uninstalling applications can also be resolved by clearing the relevant folders (I have tested dism++ and openark, and they can both delete them; I believe most cleaning software can do the same).

┏[ Zertw from  ASUS][ 3.024s][ RAM: 9/15GB][ Monday at 12:32:15 AM][]
┖[~\AppData\Local\Temp\WinGet\cache\V2_PVD\Microsoft.Winget.Source_8wekyb3d8bbwe\packages]
└─Δ  (ll).Count
63
┏[ Zertw from  ASUS][ 0.02s][ RAM: 9/15GB][ Monday at 12:33:20 AM][]
┖[~\AppData\Local\Temp\WinGet\cache\V2_PVD\Microsoft.Winget.Source_8wekyb3d8bbwe\packages]
└─Δ  (winget list | rg ' winget').Count
71
┏[ Zertw from  ASUS][ 3.14s][ RAM: 9/15GB][ Monday at 12:33:53 AM][]
┖[~\AppData\Local\Temp\WinGet\cache\V2_PVD\Microsoft.Winget.Source_8wekyb3d8bbwe\packages]
└─Δ  (winget list).Count
313

The folder seems contain some packages that I never installed ( at least I don't know what they are, nor I can remember I installed some packages similar ). You can't explain to users what the result stands for.

In fact, I mentioned this issue earlier. This folder stores the IDs of applications that Winget can manage, which may include applications installed from the Microsoft Store, applications installed through other package managers, and runtime libraries installed when downloading games through Steam. In summary, any application that was not installed using winget install and writes to specific registry keys may be present in this folder, but the results here are undoubtedly more reliable than those obtained directly via winget list.

To be honest, Winget has many drawbacks compared to other package managers on the same platform, as it cannot accurately count the number of applications it manages. I know the solution I proposed is not perfect, but it is relatively better.

To be honest, Winget has many drawbacks compared to other package managers on the same platform, and it cannot accurately count the number of applications it manages. I know the solution I proposed is not perfect, but it is relatively better.

[SorYoshino]

This is even much slower than the entire fastfetch command...

Oh, I haven't paid attention to this issue. I only compared its speed with that of scoop list.

and I don't think I want to rely on a command that hasn't been accepted by scoop/main.

I think it's just because it's not popular right now—it doesn't have at least 500 stars and 150 forks. But as long as it keeps getting developed, I'm sure it'll make it into scoop/main.

[SorYoshino]

In summary, any application that was not installed using winget install and writes to specific registry keys may be present in this folder, but the results here are undoubtedly more reliable than those obtained directly via winget list.

We cannot count only the applications installed via winget install, because due to the way winget works, we can only enumerate applications that winget is able to recognize and manage.

Regardless of whether we use the winget list command or attempt to count subfolders, it's inevitable that the results will include some applications the user doesn't even remember installing. Attempting to exclude these in order to get an accurate installation count is simply impossible. This also means that, compared to other more structured package managers, winget is fundamentally incapable of providing a clear and precise number. Therefore, it may not even be necessary to explain why such results occur — they are a direct consequence of winget’s inherently ambiguous nature.

[CarterLi]

Therefore, it may not even be necessary to explain why such results occur — they are a direct consequence of winget’s inherently ambiguous nature.

I don't think so, or I will implement it as int getWingetPackageCount() { return 100; }

People WILL ask for what the result stands for. If you replay them the line count of "winget list", no one can say it's wrong. Even it's wrong, it IS winget's fault, not fastfetch's fault. Like, you should file a issue to winget repo asking them to improve the accuracy of winget list, not argue with me about winget’s inherently ambiguous nature.

That's it. Fastfetch's responsibility is report the result of package_manager --list | wc -l as fast as possible. As for the accuracy of package_manager --list, it's the maintainer of package_manager should care.

[SorYoshino]

First, I have never believed that this is a Fastfetch issue. Second, I don't think that no one has ever discovered this issue with Winget and reported it to the Winget repo. I am not raising this point to argue with you about the ambiguity of Winget itself, but simply to suggest some possible ways to improve the user experience. Finally, thank you for your reply. Everyone has different opinions, and if my previous viewpoint made you feel offended, I sincerely apologize for that.

[CarterLi]

I have never believed that this is a Fastfetch issue.

But if you choose an unofficial and unexplainable algorithm and some people don't agree with it, it will become a fastfetch issue.

I don't think that no one has ever discovered this issue with Winget and reported it to the Winget repo

I don't either. However it's still not fixed. It suggests that MS folks think the current behavior of winget list is ok to them.

if my previous viewpoint made you feel offended

No. Please don't worry.

[SorYoshino]

But if you choose an unofficial and unexplainable algorithm and some people don't agree with it, it will become a fastfetch issue.

Thank you for the detailed explanation — it prompted me to reconsider certain aspects of the issue that I may have previously overlooked. That said, I don't believe this approach should be considered "unofficial", as the folder in question appears to be an intentional part of Microsoft's caching mechanism. In a way, it bears some resemblance to pacman's /var/lib/pacman/local structure, although their roles and functionalities are not exactly equivalent.

In any case, this point is not critical for me at the moment. I will continue to explore other possible solutions, approaching the problem from different angles in search of a more suitable approach.

[SorYoshino]

Hello, thank you for updating the code to detect the number of applications installed via Scoop!

I noticed that the current implementation uses ffFindExecutableInPath() to locate scoop.cmd and then derives the apps directory path from there. However, this logic seems to only detect applications installed under the same directory where Scoop itself is installed. In practice, Scoop itself can be installed in either the root_path or the global_path.

Is there any specific reason for detecting only a single path? Or is support for this planned in a future update?

Thank you again for your effort and contributions!

[CarterLi]

Not sure what is a root_path / global_path. Can you elaborate?

[SorYoshino]

Of course, let me explain it with an installation command and example:

Set-ExecutionPolicy RemoteSigned -scope CurrentUser
$Basic_Command = "{$(Invoke-RestMethod -Uri 'https://get.scoop.sh' -UseBasicParsing)}"
$InstallCommand = "$Basic_Command -ScoopDir '$root_path' -ScoopGlobalDir '$global_path' -RunAsAdmin"
Invoke-Expression -Command "& $InstallCommand"

If you successfully install scoop using the above command, the following content will appear in $HOME\.conf\scoop\config.json:

{
  "root_path": "D:\\Software\\Scoop\\Local",
  "global_path": "D:\\Software\\Scoop\\Global"
}

If this information is not provided, it means that the $root_path and $global_path you entered are the default locations. Not specifying the -ScoopDir and -ScoopGlobalDir parameters has the same effect. You can find more information here.

Then you can use scoop install <app> or scoop install <app> --global to install the application to root_path\apps or global_path\apps.

┏[ Zertw from  ASUS][ 0s][ RAM: 8/15GB][ Tuesday at 2:58:48 PM][]
┖[~]
└─Δ  scoop which fastfetch
D:\Software\Scoop\Local\apps\fastfetch\current\fastfetch.exe
┏[ Zertw from  ASUS][ 0.16s][ RAM: 8/15GB][ Tuesday at 2:58:57 PM][]
┖[~]
└─Δ  scoop which vim
D:\Software\Scoop\Global\apps\Vim\current\vim.exe

As for what I mentioned above, Scoop itself can be installed in either the root_path or the global_path, I saw an article a few months ago about installing it in the global_path, but I can't find a similar article now. To avoid any mistakes, we can ignore this for now.