Feature request: allow ps1 installer script to interpret PROTO_SETUP_ARGS environment variable

W1M0R commented 1 month ago

What version?

0.38.2

Which command?

irm https://moonrepo.dev/install/proto.ps1 | iex

What happened?

I want to adopt proto on a per-project basis. Projects that don't use proto, should not be affected by proto shims and bins. A simple way to do this, is to not let the proto installer modify the environment (specifically the PATH variable), and then on a per-project basis we can do something like proto activate --export pwsh (or just manipulate the environment ourselves).

Running irm https://moonrepo.dev/install/proto.ps1 | iex modifies the PATH, even if None is selected to prevent modification of the shell profile. It looks like the installer script calls into proto setup which does offer the flags I need: --no-modify-profile, --no-modify-path.

The proto.ps1 install script does seem to allow arguments, I'm just not sure how to invoke it using irm https://moonrepo.dev/install/proto.ps1 | iex. My gut feel is that I'd probably have to download the proto.ps script and then execute the script directly without piping it to iex. This is fine, but a bit clumsy.

Maybe a PROTO_SETUP_ARGS can be respected by the installer, e.g:

$Env:PROTO_SETUP_ARGS="--no-modify-profile --no-modify-path --yes"
irm https://moonrepo.dev/install/proto.ps1 | iex

Without this proposed change, ie. proto is added to the PATH by default after installation. As soon as a project uses a .prototools file to install a utility, e.g. just, then all other projects that use just (but not proto) will suddenly be greeted by the just proto shim (instead of their global just - perhaps installed via Windows scoop install just:

❯ just --version
Error: proto::tool::unknown

  × Unable to proceed, just is not a built-in tool and has not been configured with [plugins] in a .prototools file.
  │
  │ Learn more about plugins: https://moonrepo.dev/docs/proto/plugins
  │ Search community plugins: proto plugin search just

Those users shouldn't need to add a .prototools file to their project. E.g. their non-proto project worked yesterday, but after cloning a new project (that uses and installs proto), their non-proto project doesn't want to work anymore.

Trace logs?

No response

Operating system?

Windows

Architecture?

x64

W1M0R commented 1 month ago

It may also very well be, that for my particular use case I should just download the proto binary and bypass the install script, and maybe call proto upgrade and proto setup myself.

W1M0R commented 1 month ago

I'm currently using the following method to install proto and so far it looks like it is working the way I want it to:

$scriptUrl = "https://moonrepo.dev/install/proto.ps1"
$tmpScriptPath = Join-Path -Path $Env:TEMP -ChildPath "proto.ps1"
$wc = New-Object Net.Webclient
[void]($wc.downloadFile($scriptUrl, $tmpScriptPath))
pwsh.exe -ExecutionPolicy Bypass -File $tmpScriptPath --no-modify-profile --no-modify-path --yes

W1M0R commented 1 month ago

Another method for potentially solving the issue I'm having (i.e. where non-proto projects also need a .prototools file because of the shim in the PATH taking precedence by default - as it should), could be to modify the shim runner (proto-shim?), so that it has the ability to automatically handle the Error: proto::tool::unknown error, by temporarily modifying the PATH environment variable of the shim to exclude the .proto/shim and .proto/bin files, and then to execute the requested command, in that way bypassing proto entirely for that error case.

W1M0R commented 1 month ago

I still think I'm doing something wrong here. Installing just globally via proto (proto install just) should allow just to work from any directory without needing a .prototools file, am I right in saying that? Or am I supposed to run proto install just --pin global?

milesj commented 1 month ago

@W1M0R

The proto.ps1 install script does seem to allow arguments, I'm just not sure how to invoke it using irm https://moonrepo.dev/install/proto.ps1 | iex.

I've had the same thought before and couldn't find any information on this. Totally open to supporting env vars for this.

Another method for potentially solving the issue I'm having (i.e. where non-proto projects also need a .prototools file because of the shim in the PATH taking precedence by default - as it should), could be to modify the shim runner (proto-shim?), so that it has the ability to automatically handle the Error: proto::tool::unknown error, by temporarily modifying the PATH environment variable of the shim to exclude the .proto/shim and .proto/bin files, and then to execute the requested command, in that way bypassing proto entirely for that error case.

Let me dig into this a bit more. This is definitely something I want to support if possible, as I agree, onboarding should be easy and not a blocker.

I still think I'm doing something wrong here. Installing just globally via proto (proto install just) should allow just to work from any directory without needing a .prototools file, am I right in saying that? Or am I supposed to run proto install just --pin global?

Yeah the version is not pinned at all unless --pin is provided, and it's also local by default. You can use this setting however: https://moonrepo.dev/docs/proto/config#pin-latest

milesj commented 1 month ago

Landed env vars in v0.39.

moonrepo / proto