feature: add update-environment input

[mayeut]

Description:
This option allows to specify if the action shall update environment variables (default) or not.
This allows to use the setup-python action in a composite action without side effect (except downloading/installing python if version is missing).

Related issue:
fix#410

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[mayeut]

This required to be bumped to >= 1.3.0 to get getBooleanInput support. I bumped to the same version as what's being proposed in #406

[mayeut]

e2e-cache / Test poetry (Python pypy-3.7-v7.x, windows-latest) failure has nothing to do with this PR.

[brcrista]

I'd like to explore other solutions besides adding complexity to the action.

Can you just add steps to the composite action? For example:

# Save the environmentset> env.sh
# Restore the environmentsource env.sh

[mayeut]

@brcrista,
there's no way to revert a core.addPath or a core.exportVariable

For exportVariable:
If they were already set, then the ones with exportVariable could be overriden back to their original values.
If they were not set, it's impossible to unset them: https://stackoverflow.com/questions/70137245/how-to-remove-an-environment-variable-on-github-actions

For addPath, it's values are always prepended to the "current" PATH, c.f. actions/toolkit#655

[vsafonkin]

Hi @mayeut, I have some concerns about this feature. In order to use python that is installed by action without $PATH updating you should use exact paths to the installed python in a composite action. If there are any other tools in composite action which use python implicitly, then these tools will not use the version you expect. This can lead to confusion about which python version is used in some command or tool.

From my point of view an installation of python without adding to PATH may create more complications than solve problems.

[mayeut]

In order to use python that is installed by action without $PATH updating you should use exact paths to the installed python in a composite action. If there are any other tools in composite action which use python implicitly, then these tools will not use the version you expect. This can lead to confusion about which python version is used in some command or tool.
From my point of view an installation of python without adding to PATH may create more complications than solve problems.

@vsafonkin,

This is an opt-in feature. It won't change a thing for existing users. If they choose to opt-in, they shall know the implications.
Furthermore, you can easily test your own action with a GHA workflow to check if it's working as expected or not but you can't possibly test how you'll break hundreds of downstream workflows using your action if you mess up the environment. I'd rather just get ahead of this most likely event by not messing with the environment in the first place.
Last time setup-python introduced a change in environment variables, it did create some issues (#159). I'd rather avoid that.

As said in an earlier comment, it's just impossible to restore the environment as it was before running setup-python. Even if it were, I feel that it would be better solved by adding a bit of complexity in this action, centralized, rather than incurring workarounds for downstream users.

[vsafonkin]

@mayeut, ok, I see. Since the AzDev UsePython task has a similar input addToPath I think it makes sense to add this feature to the action.

[brcrista]

I'll defer to @vsafonkin on this

[brcrista]

Suggested change

	no-environment-update:
	description: 'Set this option if you want the action not to update environment variables.'
	default: false
	update-environment:
	description: 'Set this option if you want the action to update environment variables.'
	default: true

Putting boolean inputs in positive terms is usually easier for people to understand.

[mayeut]

done