u3d/installer: support custom install paths through U3D_EXTRA_PATHS

[niezbop]

Pull Request Checklist

• My pull request has been rebased on master
• I ran bundle exec rspec to make sure that my PR didn't break any test
• I ran bundle exec rubocop to make sure that my PR is inline with our code style
• I have read the code of conduct

Pull Request Description

u3d install supports custom installation paths, but does not list them correctly in the rest of the application.
This means that u3d run, package installs and such commands will not detect properly the version installed in a custom path.

This fixes this behaviour by adding an environment variable U3D_EXTRA_PATHS which is a list of additional paths to look for installed Unity versions.

Fixes #370
Fixes #371

[lacostej]

Small nitpicks on the code.

More generally I am just wondering about the ease of use of the feature. We pass arguments to install but use a variable here. Maybe a more usable way would be for u3d to keep track of those locations somewhere?

Finally after we agree on the feature, we need to update the doc.

[niezbop]

Understood. I did think about having some sort of ~/.u3d/installation_paths config file, which could be expanded when using --installation_path, but I find that a bit less robust, since it introduces some "magic" that would get broken if the installation was to be moved.

My rationale is that with the introduction of the Unity Hub and its CLI, u3d may be more and more a CI tool than a Unity developer tool. In this perspective, I think an environment variable works best since it is more easily accessible through CI platforms and easier to automate as well.

And from a user perspective, one could only have to specify the env in the .bashrc or something. Maybe we could a comment about this when installing Unity at an usual location. Something like:

You specified --installation_path LOCATION. You will need to add LOCATION to U3D_EXTRA_PATHS to make sure that the other commands can find your installation.

[bdovaz]

I'll explain our case which is very simple.

Until now we had a 256GB SSD disk for the operating system and the different versions of Unity. As you can imagine, it is very short because we work with many projects in parallel in different versions of Unity and different platforms. This makes the disk fill very fast.

Recently we have installed in two Jenkins nodes two 1TB SSD disks and that's when I found the problem of not being able to automate what I had until now in non-standard directories.

For our case, which is CI, it is good that they are environment variables because they are very easy to configure.