Two questions: portability and post-uninstall cleanup

[ltguillaume]

TLDR; Scoop's use of the term "portable" isn't portable at all, but is it meant to be? (Local)AppData folders could be junctions to the Scoop app's persistent dir. Registry keys are trickier. When uninstalling with --purge, (Local)AppData and registry traces could be removed.

I'm just starting to get familiar with Scoop and from what I've seen so far, it's pretty much exactly what I'd like to start using for systems for other people (family and friends) to keep everything up-to-date and easy to manage. It certainly beats Chocolatey on the account of transparency, folder structure and package management.

Two questions do pop up, however, and searching the Wiki and the issues did not get me answers:

Portability

What are the actual goals concerning portability? Scoop uses the term "portable" and even has a separate bucket for "non-portable" apps. As far as I can see, though, it's got nothing to do with portability, but rather with the matter of admin requirements. The term "portable" requires an app to be able to be pulled from its folder and put into another (onto another system) while its configuration is preserved (https://en.wikipedia.org/wiki/Portable_application). This is not the case with many of the apps in the main and extras bucket, as it is only the fact for those apps that are already inherently portable. There's a nice feature for persistent files, but (Local)AppData folders and registry keys seem to be completely ignored. For example, I have not (yet) seen junctions set up from AppData folders to the app's persist_dir in order to keep it actually contained. As for registry keys, e.g. WinMerge uses a single registry key for its settings, but Scoop totally ignores this fact, even when uninstalling the app.

Traces after uninstalling

This is directly connected to the portability issue. Basically, none of the package jsons I've seen handle any of the traces the apps leave on the system when uninstalling. As such, registry keys, (Local)AppData folders etc. etc. are just left there. Cleaning up after itself may not be part of the hard definition of being a "portable app" (for some people at least), but it most definitely is for "uninstalling". In my opinion this makes Scoop worse than just using an application's native installer and uninstaller. What's the general stance about this for Scoop then?

If this is all by design, then it's rather confusing for the end user: some of it is portable, some of it isn't - even though it doesn't come from the non-portable bucket - and thus all settings will be gone if you don't back up the appropriote folders and registry keys yourself.

Currently, at the very least, I'd say the use of the term "portable" is uncalled for in any case related to Scoop.

[Deide]

I'm no authority on Scoop, but here's my take:

Scoop prefers portable applications as they're easier to install, update, remove and manage. But pretty much anything goes. I do agree that we could use some cleaning up and focusing of the buckets.

I think the main reason for those missed cases is that it's difficult to investigate and keep track of all the potential ways an application may integrate with the OS. If Winmerge is leaving registry entries behind, open an issue about it in the extras repository. Scoop can specify uninstaller scripts; though because its data is technically persistent user configuration if I understand you correctly, it should only be removed upon -p or --purge.

[ltguillaume]

Scoop can specify uninstaller scripts; though because its data is technically persistent user configuration if I understand you correctly, it should only be removed upon -p or --purge.

You're right, this should be taken into account. (WinMerge uses HKEY_CURRENT_USER\Software\Thingamahoochie to save its settings).

I think the main reason for those missed cases is that it's difficult to investigate and keep track of all the potential ways an application may integrate with the OS.

That is certainly true: I make all the software I use portable (where possible and mostly without virtualization), and it is sometimes a pain. The main issue I've got with Scoop is however that it's not clear on the surface that it doesn't try to do this by default, even though it seems that "portable" is used repeatedly in the Scoop documentation.

[ltguillaume]

@lukesampson Any thoughts on this? 🙂

[ltguillaume]

@rashil2000 You've closed an issue that has never been addressed or even replied to by the devs.

[rashil2000]

Sorry I meant to convert it to a discussion

[ltguillaume]

Ah thanks, that makes sense.

[goyalyashpal]

so, scoop uses junctions for its persists? i thought it was using symlinks lol. i didn't (& still don't) quite know what a junction is... or how does it differ from symlink. tried looking up on net, it spun my head.

my initial impression were that a junction is like a reverse symlink. that is, u'd create a junction at persist/app which will create an os-managed hidden symlink at the destination say ~/app. but no, that doesn't seem to be the case.

anyhow, while i agree with the premise of problem,
example: just to be able to peacefully use lsd and work on a task, the configurations are located at mind-bogglingly 😵 scattered base locations, not to mention their logs and internal data at $env:LOCALAPPDATA etc:

# App
$env:USERPROFILE/.config/lsd/config.yaml

# Shell
$PROFILE/../profile.ps1
$env:USERPROFILE/Documents/WindowsPowerShell/profile.ps1   # <- Above one expands to this

# Terminal
$env:APPDATA/alacritty/alacritty.toml
$env:APPDATA/terminalpp/settings.json

# Editor
$env:LOCALAPPDATA/nvim/init.lua

# Tiling WIndow Manager
$env:USERPROFILE/komorebi.json
$env:USERPROFILE/.config/whkdrc

but i don't think the proposed one is a good solution:

• it is asking scoop to make modifications (creating, deleting) to outside locations
• one mistake in the manifest file, or in some implementation of scoop; and boom, whole of ~ dir gone in a sec

umh, but if it is strictly limited to deletion of only junction/symlinks, which are hard-coded (no wildcard/regex expansion in any case when executed under normal privilege) then the risk can become almost non-existent.

---

the solution or some important context was shared by the author here:
[link changed to line-specific permalink by me]

Since Scoop is already making extensive use of directory junctions, it could do the same for %(Local)AppData% folders. A few days ago I wrote a manifest doing just this for Dino: schep/bucket/dino.json

• So, on install/update, if %LocalAppData%\Dino doesn't exist or is empty, it creates a junction there to Dino's persist_dir.
• On uninstall, it checks if %LocalAppData%\Dino is a junction to persist_dir and removes the junction if so.

Originally posted by @ ltguillaume in ScoopInstaller/Extras#12271 (reply in thread)

[ltguillaume]

I think the way I implemented it should be restrictive enough to prevent any data loss. If programs really don't allow for specifying their userdata location, then I think it's allowed to use junctions to still be able to get the desired result.

The thing is, it's a solution, but nothing about Scoop's portability is a standard, so the major problem I have with Scoop is that the result for every single application you install is different. It's a roulette and all the while Scoop uses the words "portable" and "non-portable" everywhere.

As for the difference between junctions and symlinks, the most important one here is that you need administrator privileges to create symlinks (unless you change a policy).

[ltguillaume]

Here's a nice overview of the differences I found at https://stackoverflow.com/questions/9042542/what-is-the-difference-between-ntfs-junction-points-and-symbolic-links (there's more info there).

[goyalyashpal]

the major problem I have with Scoop is that the result for every single application you install is different. It's a roulette and all the while Scoop uses the words "portable" and "non-portable" everywhere.

i dont think its a problem with scoop. its a problem with windows apps and also on way things are done on windows...

scoop just simply didnt address this problem yet, which is like ohkay... like what it did is pretty good on its own as well.

ask me who, for more than a year, was manually doing all things it does automatically:

• downloading, verifying checksums, checking updates
• managing zip installs, start menu shortcuts, PATH and env vars
• keeping record of which apps are installed
• etc

[ltguillaume]

Oh yeah, guilty here, too! But it's easy enough to do that, it'll just result in small scripts to do and undo those changes, just like what Scoop manifests entail. I just wish that Scoop did the same properly, especially because they sort of advertise they are (on https://scoop.sh).

[goyalyashpal]

at least for the things like configs etc, the best way imo is to ask the upstream apps...

• one example i did: Keep configurations in separate dedicated dir even for portable install smplayer-dev/smplayer#934

the registry and env variable is a different thing, but at least scoop has that figured out for major apps.

and here too, the point of logistics comes up. due to lack of standard practices, this info is not available consolidately at upstreams. and upstream doesnt provide manifest either.

so, this error prone task ultimately falls on scoop maintainers shoulders.

[goyalyashpal]

and all the while Scoop uses the words "portable" and "non-portable" everywhere.

but i agree the marketting and branding could have avoided tooting portability.

do u have any particular tangible places in mind where the scoop markets itself as "portable"?

---

As far as I can see, though, it's got nothing to do with portability, but rather with the matter of admin requirements.

The term "portable" requires an app to be able to be pulled from its folder and put into another (onto another system) while its configuration is preserved

i agree with both these. and my stance [in discussion regarding gimp cli] was a bit conflated and hence wrong (but i am glad i didnt push it too strongly lol)

here's just a recent example of an app's instructions for portability:

https://learn.microsoft.com/en-us/windows/terminal/distributions#windows-terminal-portable

[ltguillaume]

First thing that comes to mind:

Scoop downloads and manages packages in a portable way, keeping them neatly isolated in ~\scoop. It won't install files outside its home, and you can place a Scoop installation wherever you like.

https://scoop.sh

Secondly, the distinction by the existence of a nonportable bucket implies that the applications in e.g. main and extras are portable, which is not the case for many of the apps they contain.

[goyalyashpal]

please list as many as u think prominent, as i have some ideas for scoop and will try to (no promises) address / suggest / make prs for those

[ltguillaume]

Well, for instance in https://github.com/ScoopInstaller/.github/blob/main/.github/CONTRIBUTING.md, however short their mention, it seems they actually do adhere to the same definition of portable as I described:

Portable configuration is highly preferred (by using persist).

People really want to use Scoop in its entirety as portable: #4498