Making it possible to recreate/resync scoop windows start menu shortcuts for increased portability

[hgkamath]

Scoop creates windows shortcuts in

1. (when using -g) C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Scoop Apps
2. (for scoop-managing-admin) $env:HOME\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Scoop Apps

When scoop is cooperatively managed from two Windows-OS-es/scoop-managing-admin-logins, the App windows-shortcut is created in only one place.
Use-cases:

1. VMs sharing a virtual-disk contains SCOOP
2. dual-boot windows-installations sharing a partition containing SCOOP
3. separate machine with network drive containing SCOOP etc.
4. USB drive contains scoop

One way to accomplish this is

1. have a windows-shortcuts recreation list file inside SCOOP folder that is updated whenever scoop-apps are updated
2. have a scoop syncshortcuts subcommand to refresh both Start Menu folder of current OS and login of current scoop-managing-admin. This can be automatically invokes on scoop-managing-admin who does the update, but needs to be manually executed by the scoop-managing-admin on different OS
3. a command line option -u, -g to sync only that of scoop-admin-user, or only that in the global start-menu

note that

1. the sync shortcuts is not a simple windows-shortcut file/folder-copy
2. the drive-name and mounted paths to the SCOOP folders on different machines/OS/login are different

Another idea I got while typing the above is: instead of hard-coding the windows path of exe/icon/start-folder into the windows shortcut what if it referred to them via the environment variables SCOOP and SCOOP_GLOBAL. Then maybe syncshortcuts would just have to copy/resync the local OS/scoop-managing-admin StartMenu folders.

This issue requires/depends/is also related to #4498 (Making it possible to store Scoop config in the root directory for increased portability) which is also meant to increase portability

[rashil2000]

This can already be done with the scoop reset * command.

[hgkamath]

Confirming that your suggest to use scoop reset * command recreates shims and start-menu shortcuts

When sharing scoop folder on a partition on VHDX between multi-boot Windows-host-OS or VMs

• The mount directory must be chosen with identical mount-path on all machines ex C:\vol\scoop_01\scoop, C:\vol\scoop_01\scoopg or drive_name ex: G:\
• Running scoop reset * once is necessary to fix the paths inside the shims

However, on subsequent machines, As links inside scoop directory have been fixed, only the windows start-menus need to be recreated. So I think there can be a time optimization can be done as

• scoop reset --startmenuonly *

This is related to my effort to move scoop into a VHDX file
See Also issue #4573

Please consider reopening issue.

[rashil2000]

How much time would you expect to save with the optimization? I don't think the flag is worth the effort.

[hgkamath]

In general
From reading of master/libexec/scoop-reset.ps1, scoop reset does the following

    create_shims $manifest $dir $global $architecture
    create_startmenu_shortcuts $manifest $dir $global $architecture
    env_add_path $manifest $dir $global $architecture
    env_set $manifest $dir $global $architecture
    # unlink all potential old link before re-persisting
    unlink_persist_data $original_dir
    persist_data $manifest $original_dir $persist_dir
    persist_permission $manifest $global

One might choose what to and what not to reset

The primary purpose of "scoop reset" was to cause the shims of one version of the app python27 to override another version python3 by overwriting the shims. perhaps the common shim python

scoop reset * seems to set the version overriding order back to descending lexical order. Whatever app comes later in lexical order, when reset, overrides a previously reset app.

One needs to separate

• the need to have an overriding version
• from the need to just update windows shortcuts on whatever may be the presently overriding version

IMHO, best way to do this is to have two directories

• scoop\winshortcuts
• scoopg\winshortcuts
  and copy them over when the user just wants windows shortcuts.

I could alternately, copy shortcuts over from the first machine the shortcuts were reset to subsequent machines.

[hgkamath]

How much time would you expect to save with the optimization? I don't think the flag is worth the effort.

I moved scoop from the SDD to a VHDX on the HDD, After some troubleshooting and junction repairing, I got to the point where I was ready to do a scoop reset. I think the scoop-reset took about 15 minutes.

But this is not a one time repair. It will repeat forever. Let's say

• 10 days from now, I update some apps while using multiboot-machine-1
• then 10 days later I switch back to multiboot-machine-2
• then again I need to first do scoop reset * and then do the scoop reset overriding_versions spending about 15 minutes
• So time spent accumulates if you bring a 3rd or 4rth machine into the sharing.

This is because each machine that uses the shared-scoop needs to made uptodate when apps are updated from another machine.

I have about 35 apps that update every once in a while. So this scoop resetting will need to be done on many machines and every week depending on how urgent it is to get the shortcuts in sync

Slower the machine/HDD more the time.

scoop reset has two overloaded semantics

1. inside maintenance: updating, fixing itself and choosing overriding version in its own directory
2. outside maintenance: maintaining windows-shortcuts outside of it.

The two semantics should not be clubbed for portability. So

• It is necessary to mess with the outside when the insides are updated. This is most straightforward on the local machine, and is presently what scoop reset assumes
• It becomes necessary to mess with outsides only because the insides may have been updated elsewhere.
• It is not necessary to mess with the inside when only outside needs to be updated,

I think I've made my case, that, in this use case, a lot of time will be spent on a recurring basis, and I think you see my point. With increasing VM and multiboot users and situations, I think this is going to be more commonplace and more users may bring this up.

[rashil2000]

I think I've made my case, that, in this use case, a lot of time will be spent on a recurring basis, and I think you see my point. With increasing VM and multiboot users and situations, I think this is going to be more commonplace and more users may bring this up.

It is a very peculiar use case, frankly I'm seeing it for the first time here.

The fact that you have to do scoop reset twice is intended behavior - the first is because you're moving drives (outside the scope of Scoop) and the second is, well, you need to override an existing shim because now your Scoop installation is presumably fresh (from the perspective of the drive).

The semantics of --startmenuonly flag is confusing - we will have to wrap every step of the reset in a condition, which will get convoluted soon enough if we consider adding flags for other steps as well.