Ability to override Get-UnitySetupInstance's BasePath with an environment variable about unitysetup.powershell

[jwittner]

Hey, it's funny how the world works. From what I can tell, I added support for this just 5 days ago in #244, and its available in 5.5.152-develop. Set $env:UNITY_SETUP_INSTANCE_BASEPATH_DEFAULT to a comma separated list of paths, which will be used instead of that default. Let me know if that doesn't work for you for any reason and we can re-open this issue.

You can also pass it per call to the BasePath argument in older versions, but that gets tedious for global defaults.

Note the paths can contain the wildcard characters that Get-ChildItem supports.

[ryan-beesley]

Thank you for the speedy response. This is the sort of fix I had in mind.

[ryan-beesley]

@jwittner For clarification, there should be documentation for how this should be used, in the documentation of the tool and perhaps in code comments.

I was trying to use the same pattern as $BasePath, using and array of strings like: $env:UNITY_SETUP_INSTANCE_BASEPATH_DEFAULT = @('C:\Program Files*\Unity*', 'C:\Program Files\Unity\Hub\Editor\*'). It wasn't clear that this should be a string of comma separated paths like this: $env:UNITY_SETUP_INSTANCE_BASEPATH_DEFAULT = "C:\Program Files*\Unity*,C:\Program Files\Unity\Hub\Editor\*".

I think this should support both. If it is an array, it should take the strings like $BasePath already does. The array input seems like it would be more PowerShell centric, based on how those paths might be created and passed around. Comma separated Paths stored in a monolithic string loses that characteristic.

[jwittner]

If you run help Get-UnitySetupInstance the parameter and environment var support is documented as:

 -BasePath <String[]>
    Under what base patterns should we look for Unity installs?
    Defaults to Unity default locations by platform
    Default can be configured by comma separated paths in $env:UNITY_SETUP_INSTANCE_DEFAULT_BASEPATH

    Required?                    false
    Position?                    1
    Default value
    Accept pipeline input?       false
    Accept wildcard characters?  false

I'm open to improved phrasing to clarify this of course.

Regarding the array, I think I'm ok with supporting $env:UNITY_SETUP_INSTANCE_DEFAULT_BASEPATH as both a csv as string and an array of strings, but if I'm hoping you'll make a new issue for that so it's clear that we have support for what this issue describes in the title so I'll close this again with that understanding. =)

[ryan-beesley]

I didn't realize that I could have just used Get-UnitySetupInstance -BasePath @('C:\Program Files*\Unity*', 'C:\Program Files\Unity\Hub\Editor\*'). 🤦 Still, having $env:UNITY_SETUP_INSTANCE_DEFAULT_BASEPATH is a tremendous help and I define it as one of my system variables to make it so that I don't have to manage it each session. Winning.

I was setting it up in PowerShell when I was trying to figure things out, and I assigned the array of strings to $env:UNITY_SETUP_INSTANCE_DEFAULT_BASEPATH and it returned no results. In hindsight, this makes perfect sense. I was effectively trying to use $env:UNITY_SETUP_INSTANCE_DEFAULT_BASEPATH to accomplish what the -BasePath parameter does.

So now I'm not sure what I'm asking makes sense or needs to be considered. The idiomatic PowerShell way would be to create a String[] and pass that in as an argument. Allowing the $env:UNITY_SETUP_INSTANCE_DEFAULT_BASEPATH environment variable to support a PowerShell String[], only makes sense when you create the environment variable from within a shell or as part of the $PROFILE. I still think a case could be made that $env:UNITY_SETUP_INSTANCE_DEFAULT_BASEPATH should take both String[] and StringOfCsv, because for platforms other than Windows modifying your $PROFILE might still be the way to create environment variables, and a string array is easier to manage in a PowerShellesque way.

I'll open it, and you can decide if you want to close it, understanding more of my request.