Closed W1M0R closed 1 month ago
@W1M0R To start, PROTO_HOME
is not required. It just defaults to ~/.proto
if not defined. It really only needs to be set when changing to a different location then that, but our proto setup
just writes it to the profile anyways.
"\\?\C:\Users\user2\go\bin"
- I don't know why this is in the output (I suspect it might have to do with the go plugin globals) - but the format uses UNC path, which is strange. And it also inserts a non-proto package in between the proto paths. Unless this is the proto version of go somehow installed outside the proto folders.
proto activate
includes bin directory paths from all tools, for both locally installed bins (in the tool directory itself), and globally installed bins (via a package manager or something else). So that go/bin
path is coming from the go plugin.
As for the UNC path, does that actually cause issues? Rust just uses UNC internally when things are canonicalized.
I've seen the UNC path cause issues on Windows in other environments:
But in terms of proto, go
executes as expected.
I'm guessing this check for PROTO_HOME is not such a big deal then:
Ah yeah. That's why it's a warning right now, but it's more like an informational message.
I'll look into trimming UNC, because I hate dealing with them anyways.
Fixed both of these in 0.39.1
What version?
0.38.2
Which command?
proto activate --export pwsh
What happened?
To prevent
proto
from breaking the environment for non-proto projects, I am currently taking the approach of manually setting the process environment variables in proto projects, by running a lightweight script to configure the environment before executing proto (or other commands that need to run in the proto environment).These are the environment setup steps:
The output of
proto activate --export pwsh
is:There are two things strange here:
"\\?\C:\Users\user2\go\bin"
- I don't know why this is in the output (I suspect it might have to do with the go plugin globals) - but the format uses UNC path, which is strange. And it also inserts a non-proto package in between the proto paths. Unless this is the proto version of go somehow installed outside the proto folders.$env:PROTO_HOME
.Searching for
PROTO_HOME
in the codebase, it looks like it is used by shims or elsewhere, so it should probably be set. In my script I am settingPROTO_HOME
andPATH
manually, but ideally I would just callproto activate --export pwsh | iex
(or something to that effect), and it would setPROTO_HOME
andPATH
.This installation approach is not the conventional method, so I understand that
PROTO_HOME
can typically be assumed to have been set at installation time - at least for the PowerShell profile (not in the user environment variables - I think).To accomodate this non-conventional installation method, the
proto activate
command could potentially check if aPROTO_HOME
is present, and if not, calculate a value for it (probably based on the location of the running proto instance) and add it to the list of exported variables. Alternatively, always exportPROTO_HOME
since overwriting an existing value shouldn't really matter.Trace logs?
Operating system?
Windows
Architecture?
x64