make install.sh viable in non-interactive mode

[jeffhammond]

Either it is undocumented or unsupported, but I cannot find a way to run ./install.sh in non-interactive mode, which is critical if I am to use OpenCoarrays in Travis CI.

opencoarrays will be installed in /home/travis/build/jeffhammond/PRK/PRK-deps/opencoarrays/opencoarrays/1.6.1
Ready to rock and roll? (Y/n)
No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.
The build has been terminated

See https://travis-ci.org/jeffhammond/PRK/jobs/133685882 for details.

[rouson]

@jeffhammond

Currently, the only option for a non-interactive installation is to use the yes command (which I install with MacPorts on OS X and appears in a fresh installation of the Lunbuntu Linux distribution -- not sure about other distributions). As you might know, "yes" emits a stream of "y" answers to standard output, which can be piped to an installer:

yes | ./install.sh

I could mention this in our documentation, but maybe the better approach is for me to add an option that does the same thing. How about the following?

./install.sh --yes-to-all

with the equivalent short form

./install.sh -y

or if you have another suggested approach or suggested name for the flag, please let me know.

One very important point: if our installer detects missing prerequisites and the user hasn't overridden the prerequisites with various flags, then the installer attempts to download and install the prerequisites, which might require first installing secondary prerequisites and so forth. Thus, depending on the system configuration, the installation process can be lengthy, require network access, and involve installing several new packages. I hesitated to do all of the above non-interactively and therefore wanted user approval and awareness, but I do like the idea of providing a non-interactive option via a flag so hopefully this satisfies your request. Feedback is welcome.

[jeffhammond]

@rouson That all sounds fine to me. Given that my single use case for this is Travis CI, it is safe to assume network connectivity, as well as tolerance to long installs, as many of my other Travis CI setups are building MPICH from source every time as well.

This is a related, perhaps stupid question, but does install.sh try to brew install mpich before downloading and building from source? Obviously, there are other package managers, so perhaps an option like --packman={brew,macports,apt,yum} would be useful?

I will try the yes-based solution now.

[jeffhammond]

@rouson It does not appear that Macports is required to get yes, as I do not use Macports and it is in the system directory already:

$ uname -rs
Darwin 15.5.0
$ which yes
/usr/bin/yes

[rouson]

Glad to hear that. I'll ensure that this gets addressed in an upcoming release -- probably within the next 1-2 weeks.

[jeffhammond]

By the way, I just switched to installing all the dependencies myself and using CMake directly, so install.sh isn't critical for me.

[zbeekman]

@jeffhammond Have your questions been adequately answered? Are there any actionable items for us? (Improving documentation of install.sh, or changing behavior, adding functionality, etc.)

If not let's close this issue.

[rouson]

@jeffhammond and @zbeekman, I forgot to add the -y and --yes-to-all options before closing this. I'll reopen the issue and then close it after merging a new pull request that adds these options. I expect to submit the pull request this evening.

One wrinkle arises when the user pass -y or --yes-t-all and specifies an installation directory that requires sudo privileges. In that case, the script will still pause after prompting the user to enter a password. This happens after the package in question has been built so, it's a minimally interactive build process. The user also has the option to launch the script via "sudo ./install.sh -y" to bypass the need to enter a password later. The downside of that approach is then everything is done using sudo privileges rather than just the "make install" step.

I think the above is reasonable behavior. If anyone disagrees, let me know.

[jeffhammond]

This is reasonable behavior.

[zbeekman]

@jeffhammond the --yes-to-all flag was added in the latest release. Please let us know if you encounter any issues with it.

[jeffhammond]

I won't encounter any issues with it because I switched to direct invocation of CMake: https://github.com/ParRes/Kernels/blob/master/travis/install-opencoarrays.sh#L56.