Export MSYS2_ROOT environment variable

[MehdiChinoune]

Fixes partially #227

[eine]

This has been requested before, but I'm not sure we want to have it explicitly. This is typically requested for non-recommended use cases, such as adding one of MSYS2's bin locations to the PATH. We should encourage users to instead use the path-type option and/or to package their tools with PKGBUILD. As commented in #227 (comment), if users really need to know the location of the MSYS2 installation, they can get it with cygpath -m /. They can wrap that in a call from any other terminal.

@lazka @jeremyd2019 @Biswa96 what do you think?

[lazka]

Two alternatives that come to mind:

• Make it an action output, so it's documented and not using global env vars
• Or give an example somewhere how to use cygpath and use the result in future non-msys2 steps

[windelbouwman]

This has been requested before, but I'm not sure we want to have it explicitly. This is typically requested for non-recommended use cases, such as adding one of MSYS2's bin locations to the PATH. We should encourage users to instead use the path-type option and/or to package their tools with PKGBUILD. As commented in #227 (comment), if users really need to know the location of the MSYS2 installation, they can get it with cygpath -m /. They can wrap that in a call from any other terminal.

@lazka @jeremyd2019 @Biswa96 what do you think?

I understand that users should be recommended to use the msys shell, however, one problem with this is that I can only have one environment shell at a time. Say I have a python virtual environment, how do I combine it with an msys2 environment? Can I nest environments? The reason to expose for example the path to the root is to allow msys2 to be used in a way that it is not the primary environment, for example in case of python virtual env, or a rust build environment (there are probably more usecases).

[MehdiChinoune]

This has been requested before, but I'm not sure we want to have it explicitly. This is typically requested for non-recommended use cases, such as adding one of MSYS2's bin locations to the PATH. We should encourage users to instead use the path-type option and/or to package their tools with PKGBUILD. As commented in #227 (comment), if users really need to know the location of the MSYS2 installation, they can get it with cygpath -m /. They can wrap that in a call from any other terminal.
@lazka @jeremyd2019 @Biswa96 what do you think?

I understand that users should be recommended to use the msys shell, however, one problem with this is that I can only have one environment shell at a time. Say I have a python virtual environment, how do I combine it with an msys2 environment? Can I nest environments? The reason to expose for example the path to the root is to allow msys2 to be used in a way that it is not the primary environment, for example in case of python virtual env, or a rust build environment (there are probably more usecases).

MSYS2 MINGW environments have Python and Rust.

[eine]

@windelbouwman, I feel some misconceptions in your writing. The environment, a shell and a python virtual environment are different things. "Nesting environments" is a confusing concept. Python and bash are interpreted languages, which do require an interpreter to understand and execute commands. The interpreter of Python is typically python and the one for bash is typically bash. As long as you can find the interpreters (either through a relative or an absolute location), you can execute one within the other. You can execute bash from python or python from bash. In bash, you do it directly; in Python, you need to use system(), check_call() or similar functions.

This Action provides a helper/wrapper executable, which is available in the PATH and which you can use to execute commands in MSYS2 shells without explicitly knowing the location. See https://github.com/msys2/setup-msys2#usage:

  - shell: powershell
    run: msys2 -c 'uname -a'

So, if you wanted to execute some commands in a MSYS2 shell, from Python, you would do:

  - shell: python
    run:
      from subprocess import check_call
      check_call(['msys2', '-c', 'uname -a'], shell=True)

Note that this is not exclusive to Python or bash. This Action is written in JavaScript (another interpreted language) and a very similar approach is used: https://github.com/msys2/setup-msys2/blob/main/main.js#L199-L207.

Naturally, you can pass a file instead of hardcoding the commands in the call.
Environment variables can be used to select which variant of MSYS2 to use: https://github.com/msys2/setup-msys2#msystem.

Furthermore, if you really want to add MSYS2 bin dirs to some environment, you can explicitly tell this Action where to install MSYS2: https://github.com/msys2/setup-msys2#location.

Overall, as @MehdiChinoune suggested, I recommend to use Python or Rust within MSYS2 if you rely on dependencies which are only available on MSYS2.

[eine]

Or give an example somewhere how to use cygpath and use the result in future non-msys2 steps

@lazka, https://github.com/msys2/setup-msys2/blob/main/.github/workflows/Test.yml#L48-L83 and https://github.com/msys2/setup-msys2/blob/main/.github/workflows/Test.yml#L86-L127 show (and test) how to call any msys2 command from either cmd or powershell. I added two new examples showing how to save the location to a variable, either from powershell or from python:

setup-msys2/.github/workflows/Test.yml

Lines 400 to 408 in 066de4c

	- shell: pwsh
	run: |
	$Env:MSYS2_ROOT = msys2 -c 'cygpath -m /'
	$Env:MSYS2_ROOT
	- shell: python
	run: |
	from subprocess import check_output
	MSYS2_ROOT = check_output(['msys2', '-c', 'cygpath -m /'], shell=True).decode('utf-8')
	print(MSYS2_ROOT)

See https://github.com/msys2/setup-msys2/runs/6573587546?check_suite_focus=true.

[lazka]

I've created #404 which is similar.

While using cygpath is an alternative, I think letting people figure that out, just to get a path they can add to PATH is too much to ask.