Isolate scoop path to separate environment variable

[masaeedu]

I have lots of other utilities that are constantly fiddling with my user PATH, and sometimes these utilities and scoop get into fights and wreck things. It'd be nice if scoop could limit all its changes to a single $env:SCOOP_PATH variable, which I could interpolate into my own PATH at whatever position (and hence precedence) I want.

[excitoon]

Hi. Please follow my PR at #2917 . This is a step for making isolated environment variables required by applications.

[lefb766]

This would also solve an issue I have.

In the current implementation, it is tricky to get shims override commands in system dirs. For example, zeit/now-cli wouldn't be able to override rktools' now.exe out of box.

This is due to Windows nature in which system PATH will be prepended before user PATH. As a workaround, I ended up prepending another $HOME\scoop\shims to $env:Path in the $profile.

[nonatorw]

I created an idea that refers to it, that I think it could be a good inclusion to the discuss: #5059.

---

I recently started to use scoop at my work computer, and I have environment variables that I need to include in the PATH to use some tools that scoop can't manage. However, every time that I run scoop update --all or scoop cleanup --all, all my variables included in the PATH are changed for their absolute paths. It is troublesome because some of that variables need to be changed at runtime.

So, I don't know the impact of this suggestion to the whole project, but... why scoop doesn't use environment variables (that can be included in the PATH) and update them, instead of put the applications' paths directly in the PATH, refreshing it and killing every variable's reference?

~Individual environment variables for each app, depending on the quantity of apps to include in the environment, could be troublesome to manage.~ (...)

EDIT: thinking better about it, if every app that need to be included in the PATH creates an environment variable to refer itself, and it's included in it by reference, it's much neat and easy to manage, imho.

(...) ~However,~ working in that way could avoid problems of compatibility with other apps that are not managed by scoop.

A complementar suggestion: to declare a SCOOP_APPS_PATH variable, and include all scoop managed's apps in it, and then do reference to it in the PATH variable.

[candrapersada]

is there an option to make \.config\scoop portable?

[nonatorw]

Guys, why this issue isn't evolving? Is there any block?

[rashil2000]

No block as of now, contributions welcome :)

[nonatorw]

No block as of now, contributions welcome :)

I'll see what I can do, but Dot.Net is not my main skill. Thanks

[rashil2000]

The codebase does not use .NET or C# directly, so no need to worry about that, it's just one language - PowerShell (which is internally based on .NET).

[hagaigold]

No block as of now, contributions welcome :)

@rashil2000, what will be a reasonable migration to a SCOOP_PATH env, if we apply this change?
maybe with scoop update?

all my variables included in the PATH are changed for their absolute paths.

This is different issue: getEnvironmentVariable can't handle env variables without expanding them.
Actually, install.ps1 do it correctly, while scoop not.

Should we have a different issue for this?

[hagaigold]

just saw this: #5395 there was a PR to solve the %% expanding issue.

[rashil2000]

@rashil2000, what will be a reasonable migration to a SCOOP_PATH env, if we apply this change? maybe with scoop update?

Yes

[hagaigold]

ok, I'll give a shot on this one. Can you point me how do I run the tests suite?

[rashil2000]

.\test\bin\init.ps1
.\test\bin\test.ps1

[hagaigold]

This feature can be tested from here: repo: https://github.com/hagaigold/Scoop branch: develop

[melMass]

@hagaigold Is there a PR opened here already?

[hagaigold]

@hagaigold Is there a PR opened here already?

Not yet.
I think it is a kind of "critical" change, so hopefully someone else beside myself will want to test it.

[melMass]

Thanks @hagaigold, I will, and merge main back too, but I think you should open a PR. This will get tested by more and mainly get reviewed by maintainers which should help speed up the integration :)

[hagaigold]

and merge main back too

I am not sure this will work.
The changes are based on the develop branch which is 1 year ahead.

[melMass]

Then develop 😅 , I meant the base branch you used

[CEbbinghaus]

Just came across this issue, Wish I had found it before raising the PR but so be it. PR open which implements this (albeit VERY crudely). Feedback welcome

[rashil2000]

Originally posted by @Chaoses-Ib in #5874:

---

Bug Report

Current Behavior

When PATH is longer than 8192 characters, Scoop cannot run git to update.

Expected Behavior

The maximum length of an environment variable is 32767 characters on Windows. Scoop should work if PATH is longer than 8192 characters but less than 32767 characters, or at least print a warning.

Additional context/output

> $env:PATH = "${env:USERPROFILE}\scoop\shims;" + 'C:\Windows\System32;'*410
> $env:PATH.length
8229

> git
usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
...

> scoop install xx
Updating Scoop...
'git' is not recognized as an internal or external command,
operable program or batch file.
Update failed.
Couldn't find manifest for 'xx'.

> scoop update xx 
Updating Scoop...
'git' is not recognized as an internal or external command,
operable program or batch file.
Update failed.

Possible Solution

8192 characters is the maximum environment variable length accepted by CMD. And Scoop uses CMD to run git here:

https://github.com/ScoopInstaller/Scoop/blob/f93028001fbe5c78cc41f59e3814d2ac8e595724/lib/core.ps1#L131-L138

To relax the length limit to 32767 characters, this usage of CMD needs to be removed. Alternatively, truncating PATH and printing a warning if PATH is too long would be simpler. If the latter is preferred, I can make a PR.