Have to decide what to do if user wants to override version of pre-installed dagger. Do we install the desired dagger CLI version in the <install location prefix>/bin if set, or else just install in the default location? or intentionally clobber the existing version in its location (prob not), or install in either the default or designated spot and then make an adjustment to the PATH variable that will last for this actions invocation to give the new version precedence (and/or find a way to persist the PATH variable), or uninstall the previous version (prob not), or ...

I was just thinking about this and wanted to open an issue, when I saw your PR.

I think it makes sense to allow users using a pre-installed version, especially when moving to or between environments.

The new Depot integration comes to mind: reducing friction when onboarding or just building a PoC is always good. That was part of the appeal when I first gave Depot a try.

Have to decide what to do if user wants to override version of pre-installed dagger. Do we install the desired dagger CLI version in the /bin if set, or else just install in the default location? or intentionally clobber the existing version in its location (prob not), or install in either the default or designated spot and then make an adjustment to the PATH variable that will last for this actions invocation to give the new version precedence (and/or find a way to persist the PATH variable), or uninstall the previous version (prob not), or ...

A third option (which is what some actions do) is install Dagger in a custom location (eg. tool cache) and use it from there. The action can provide the location as an output if anyone wants to use it/add it to PATH, but in most of the cases, people will probably just want to use it through the action.

At some point, it might also make sense to create a separate setup-action for downloading the CLI.