respect UV_NO_MODIFY_PATH

[2bndy5]

I would like to use this action to setup uv as part of a composite GitHub action. But I do not want to alter the runner's PATH because that may be perceived as an unexpected side effect, especially if the calling workflow wants a specific/different version of uv installed. I see that I can use tool-bin-dir to set the install location. So I could easily invoke uv from that specified path.

[eifinger]

Each added configuration option adds maintainance overhead so I have to weight the benefit of adding it. Can you elaborate a bit more, maybe with an example, where your feature request is needed. So far I understand that you identify it as a feature that MIGHT be wanted by others than you?

[2bndy5]

I was thinking an env variable would suffice.

- uses: astral-sh/setup-uv@v6
  env:
    UV_NO_MODIFY_PATH: 1 # or true or 'on'

Can you elaborate a bit more, maybe with an example, where your feature request is needed. So far I understand that you identify it as a feature that MIGHT be wanted by others than you?

I'm not sure I can identify all uses where not adding uv to the PATH is useful. But, this behavior is a pretty typical offering for actions/setup-*** actions.

In making a composite action, it is best to not modify the calling workflow's PATH. That way there are less surprises in steps that follow usage of a composite action. For an example, see collapse snippet below.

I would note that, in the case of a composite action, the calling workflow might expect a version of uv that github.actor would specify, not the version of uv that a composite action installed without their knowledge.

---

This isn't a high priority. I managed to achieve this behavior using the suggested bash and pwsh installer scripts while UV_NO_MODIFY_PATH=1 for a single step's env. But I ended up using nushell script to avoid having duplicate steps for each native shell; some self-hosted windows runners do not actually have bash available.

snippet

    - name: Setup uv
      shell: nu {0}
      env:
        UV_NO_MODIFY_PATH: 1
        UV_VERSION: '0.8.12'
      run: |-
        let action_path = $env.GITHUB_ACTION_PATH | path expand
        $env.UV_INSTALL_DIR = $action_path | path join 'bin'

        $env.UV_CACHE_DIR = $env.RUNNER_TEMP | path join 'my-action-specific-cache'
        if (not ($env.UV_CACHE_DIR | path exists)) {
          mkdir $env.UV_CACHE_DIR
        }

        print $"\n(ansi purple)Installing uv version ($env.UV_VERSION)(ansi reset)"
        let is_windows = (sys host | get 'name') == 'Windows'
        let uv_installer_url = if $is_windows {
          $"https://astral.sh/uv/($env.UV_VERSION)/install.ps1"
        } else {
          $"https://astral.sh/uv/($env.UV_VERSION)/install.sh"
        }
        let installer = http get --raw --redirect-mode follow $uv_installer_url
        if $is_windows {
          ^powershell -ExecutionPolicy ByPass $installer
        } else {
          $installer | ^sh
        }

[eifinger]

[...] But, this behavior is a pretty typical offering for actions/setup-*** actions

Can you give an example? I checked actions/setup-java and actions/setup-node and both always alter the PATH

[2bndy5]

[...] But, this behavior is a pretty typical offering for actions/setup-*** actions

Can you give an example? I checked actions/setup-java and actions/setup-node and both always alter the PATH

Oh, I hardly ever use those. I was really just referring to actions/setup-python and some other third-party "setup" actions.

I don't seem to have the specific info you want. No harm done if this request is rejected.