[Feature] Multiple installations of the same program
Describe the solution you'd like
Since every program in official buckets is portable it must be very easy to make it possible to create multiple installations of the same program with different persist folders and\or of different versions of the same program
Example:
scoop install firefox --label test
or
scoop install firefox#test
Will create apps/firefox#test and persist/firefox#test folders and install program there.
Also it should add Firefox#test or something more pretty like Firefox [test].
This app must be threaten as different from original one so it must have it's own install.json.
But i don't really know what to do with shims :). Shim with # in it looks strange
+1, reall love to have this.
I would extend this by being able to specify different shortcut names. For example, scoop install firefox --shortcut-name-display "Firefox Personal" resulting in a searchable shortcut in the start menu called Firefox Personal and scoop install firefox --shortcut-name-display "Firefox Work" resulting in a searchable shortcut in the start menu called Firefox Work. Both must be of the same most recent version, but the installations are treated as completely separate, not interacting with each other in any way whatsoever.
Additionally, I recommend, that it shouldn't be necessary to fiddle around with actual folder structures. This should be handled by Scoop primarily internally. Maybe add an optional CLI option, but do not make it mandatory for the user to manage the folders, like apps and persist in above example. After all, the UX from how the program is called by the user is most important, not how it works behind the scenes.
All that said, this is a super useful and very important feature, once you are in that niché to need it at all. It's sad to see, that the original post was made close to a year ago, without intermediate updates. Is there any way to speed up process on this matter?
+1, very needed.
Also, remember that some apps have an env_set config, so Scoop must change a core behavior in this scenario.
I think it can handle this by setting environment variables in shims, not in the system environment, but I don't know if that's possible or not.
Also, some environment variables are not used for the installed program and are used globally by other programs, like Chrome, which has CHROME_EXECUTABLE that some other programs use to find and run Chrome.
So, we have some local and global environment variables that must be specified by the program manifest to show how to set them in a multiple installation scenario.
For example, this:
"env_set": {
"Var1": "$dir\\name.exe",
"Var2": "$dir\\data"
},
must be changed to this:
"env_set": {
[ "Var1", "$dir\\name.exe", true ], <--------- set var in system env
[ "Var2", "$dir\\data", false ] <------------- set var in shims
},