Consider removing the `pip-install` input

[woodruffw]

Description:

I saw that actions/setup-python added a new input, pip-install, with version 6.1.0 (in #1201).

This appears to be the core of the change:

setup-python/src/setup-python.ts

Lines 26 to 37 in 83679a8

	async function installPipPackages(pipInstall: string) {
	core.info(`Installing pip packages: ${pipInstall}`);
	try {
	const installArgs = pipInstall.trim().split(/\s+/);
	await exec('python', ['-m', 'pip', 'install', ...installArgs]);
	core.info('Successfully installed pip packages');
	} catch (error) {
	core.setFailed(
	`Failed to install pip packages from "${pipInstall}". Please verify that the package names, versions, or requirements files provided are correct and installable, that the specified packages and versions can be resolved from PyPI or the configured package index, and that your network connection is stable and allows access to the package index.`
	);
	}
	}

Unfortunately, I think any widespread usage of this input is going to cause significant negative effects:

1. As implemented, this appears to install packages directly into the global (runner-level) Python environment, which may or may not be visible to individual runtime (virtual) environments. This means that end users will see inconsistent installation results from using this input, despite the input implying that the packages are always installed.
2. As a knock-on of the above, doing these kinds of global installations can have weird effects on subsequent resolutions (e.g. preventing pip from installing an expected transitive dependency, because some top-level package constrains it). In the best case this results in suboptimal or stale resolutions; in the worse case it results in broken resolutions (or resolutions of things the user intentionally wants to exclude). More broadly, this is why PEP 668 strongly discourages external environment modification.
3. More broadly, this presents an auditability/discoverability problem: someone who does pip-install: foo bar ... runs the risk of forgetting to update those dependencies. Moreover, GitHub's own ecosystem of tools (like Dependabot) won't update these kinds of inlined dependencies. I think this is a non-ideal position to put users in; the official actions ecosystem should guide users towards doing the right thing s(lockfiles, controlled dependency upgrades).
4. Finally, I suspect this just won't work with a lot of more recent Python packaging tooling. uv, for example, likely won't see these packages (since it doesn't consider the global environment), which means that users will be presented with a confusing error state when they mix setup-python with uv.

Justification:

Per above: explicitly encouraging users to do global-state package installations like this is going to cause a lot of confusing error messages for people with Python codebases. It's also a step backwards in terms of dependency auditability/discoverability.

Are you willing to submit a PR?

Yes, I'd be happy to send a PR reverting this.

[woodruffw]

Also, for context: I believe the only reason this actually works at the moment is because of a "temporary workaround" in the Linux runner images themselves: actions/runner-images#10794

Once that workaround is removed (which it should be, because it's roughly as dangerous in terms of breakage as this change), this action input will stop working (since pip will refuse to install into an externally-managed environment).

[priyagupta108]

Hi @woodruffw 👋,
Thank you for the feature request. We'll investigate it and get back to you as soon as we have updates.