Is it a good idea to replace (sub-)apps scattered around a system with links to scoop shims?

[wisdomtooth]

Like so:
foreach ($shim in dir $scoop_global\shims\*.exe) {foreach ($linked in dir $shim.name -r | select fullname) {New-Item -Force -ItemType SymbolicLink -Path $linked -Target $shim}}

I know the standard answer to this is "Of course not! There is a high chance it'll break a lot of stuff," but hear me out. Why have dozens of copies of 7zip, or similar apps, scattered around app folders? Wouldn't it be great if all apps in a system linked back to a central app pool (if not db)? Of course, different apps may require different versions of other apps they use in common, or even various flavours of the same app version, but that's all easily managed in a central app db. Scoop already does that. In fact, isn't that something OSs should do natively (and in so doing have greater security around apps installed in the system, rather than let them be filed away in sub-sub-sub-...-sub-folders anywhere in storage?

Just a thought.

[rashil2000]

Hey!

I'm not sure I understand your question. Could you explain what you're trying to achieve with the code snippet, preferably with an example app?

[wisdomtooth]

Here's the deal: I'm here bc I'm obsessed with keeping my system brand spanking new, of course, with the shiny latest versions of each and every software I installed. Before leveled all 7zip instances in my system to the latest, the versions of these were all over the place:

So I took a plunge, and copied over a link to the latest scoop version. Obsessive, I admit. But it got me thinking (and that's the gist of this question): shouldn't OSs work exactly like that, with a central app db, that grows and is updated with the latest versions of every app (not overwriting older versions, of course), as new suites are installed?

[rashil2000]

that grows and is updated with the latest versions of every app

This isn't always a good idea. App developers usually ship all dependencies with their apps because they want neither the OS nor the user to care about those dependencies. Moreover app developers don't keep the latest versions of the dependencies for 2 reasons:

• the latest version of the dependency is not compatible with their app (which happens to be the case with 7zip)
• they just forgot to update them. Moreover, since they're not using all the functionality of the dependency, they don't want to fix something that's not broken.

[wisdomtooth]

since they're not using all the functionality of the dependency, they don't want to fix something that's not broken.

Aren't apps being constantly updated precisely bc devs found something broken (or that could break, i.e. vulnerabilities), in addition to further enhancements?

they just forgot to update them.

That's precisely the problem.

the latest version of the dependency is not compatible with their app

They can still list an old version as the dependency.

App developers usually ship all dependencies with their apps because they want neither the OS nor the user to care about those dependencies.

OTOH, having apps refer to public libraries (i.e. dependencies), rather than private ones, increases security.

Sudden;y, it dawned on me that what I'm talking about is precisely how Python and Linux(?) work, and my question reduces to a simple: why can't Windows be more like Linux?

Perhaps the next step for Windows package managers like Scoop is letting installers simply refer to dependencies, rather than shipping them all in one big install. And that will take Windows one step closer to Linux level of security.

[rashil2000]

Aren't apps being constantly updated precisely bc devs found something broken (or that could break, i.e. vulnerabilities), in addition to further enhancements?

Apps, yes, their dependencies, not so much

They can still list an old version as the dependency.

They need to ship it too, just listing won't help

OTOH, having apps refer to public libraries (i.e. dependencies), rather than private ones, increases security.

There's no question of private or public libraries, just different versions.

Why would Windows need to be more like Linux? Windows, despite having a lack of OS-level package manager, never faces the problem of missing or incompatible dependencies. If you've used Linux as a daily driver, you'd know what I'm talking about - all apps depend on the same system level dependencies, which prevents app updates from happening in a timely manner, and even if everything is up to date, a random app or service will suddenly break some day because of backward incompatibility with a Python version or a Qt library version.

Both of them have a vastly different security model, neither is "more secure".

[wisdomtooth]

If you've used Linux as a daily driver, you'd know what I'm talking about - all apps depend on the same system level dependencies

Yes! That's what I'm talking about (though I've only dabbled in Linux, and mostly when I used a Mac).

even if everything is up to date, a random app or service will suddenly break some day because of backward incompatibility with a Python version or a Qt library version.

Isn't that solved by apps specifying version ranges they can work with? At least that's what I see when I run pip, for instance.

They need to ship it too, just listing won't help

Isn't that how pip and apt-get work? What if scoop gave devs the option of either shipping the dependencies they use, or simply declaring them in the install bundle (with name and version range)? Scoop would then search through the buckets the user has chosen to trust, and install the latest dependencies versions in the declared ranges (if not already installed in the scoop folder).

[rashil2000]

Isn't that solved by apps specifying version ranges they can work with? At least that's what I see when I run pip, for instance.

You can't do that for system level apps, you can only have one version at a time. And if that version is too old or too new, well, you're going to have a lot of trouble.

What if scoop gave devs the option of wither shipping the dependencies they use, or simply declaring them in the install bundle

You can already specify dependencies (and optionally, their versions) for an app in the manifest itself.

[wisdomtooth]

You can already specify dependencies (and optionally, their versions) for an app in the manifest itself.

You're ahead of me, then.

You can't do that for system level apps, you can only have one version at a time.

OTOH, sounds like I was onto something here:

shouldn't OSs work exactly like that, with a central app db, that grows and is updated with the latest versions of every app (not overwriting older versions, of course), as new suites are installed?