macOS travis builds recently started failing (travis caches were cleared
recently, maybe related). python2 is reasonably covered by linux CI. Not
going to waste time on it for macOS CI.
==> Installing python@2
==> Downloading https://homebrew.bintray.com/bottles/python@2-2.7.14_3.el_capita
==> Pouring python@2-2.7.14_3.el_capitan.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/2to3-2
Target /usr/local/bin/2to3-2
is a symlink belonging to python. You can unlink it:
brew unlink python
To force the link and overwrite all conflicting files:
brew link --overwrite python@2
To list all files that would be deleted:
brew link --overwrite --dry-run python@2
Possible conflicting files are:
/usr/local/bin/2to3-2 -> /usr/local/Cellar/python/2.7.12_1/bin/2to3-2
/usr/local/bin/2to3-2.7 -> /usr/local/Cellar/python/2.7.12_1/bin/2to3-2.7
/usr/local/bin/idle -> /usr/local/Cellar/python/2.7.12_1/bin/idle
...
Homebrew changed a few formulae to meet their standards. "python3" was renamed
to "python", and "python2" to "python@2".
As for why, read this announcement: https://brew.sh/2018/01/19/homebrew-1.5.0
Since we install Python 3 via homebrew anyway, we now do the same for Python 2
as well. We do that because the system Python 2 of macOS comes without pip
installed and this way seems cleaner than doing "sudo easy_install pip".
The Python 2 formula is keg-only now, so it doesn't interfere with the system
Python 2. Therefore we have to add its executables to $PATH ourselves.
With 6fa0a0a516 the neovim-ruby gem installs successfully, but
ruby_spec.lua can't find it: g:ruby_host_prog needs to be set correctly.
Just skip the whole thing for now, so that CI builds don't fail.
The llvm repos commonly have access issues, so removing them will
improve stability of the Travis builds.
Filtering check_log's output through asan_symbolize also avoids the
version dance every time a new clang version makes its way into Travis.
provider#node#can_inspect will fail on some systems because it is common
to have old node versions in OS (any Linux OS that has LTS releases)
and CI (Travis, Appveyor).
NODE_PATH can be trivially set with VimL.
Build scripts don't have to set it for the nodejs tests to work.
NODE_PATH is optional to begin with and is used only as a workaround
for the neovim node.js host.
ci: install nodejs 8 in Appveyor, Travis
provider: check node version for debug support
Resolve https://github.com/neovim/neovim/pull/7577#issuecomment-350590592 for Unix.
provider: test if nodejs in ci supports --inspect-brk
nodejs host for neovim requires nodejs 6+ to work properly.
nodejs 6.12+ or 7.6+ is required for debug support via `node --inspect-brk`.
provider: run cli.js of nodejs host directly
npm shims are useless because the user cannot set node to debug mode via
--inspect-brk. This is problematic on Windows which use batchfiles and
shell scripts to compensate for not supporting shebang.
The patch uses `npm root -g` to get the absolute path of the global npm
modules. If that fails, then the user did not install neovim npm package
globally. Use that absolute path to find `neovim/bin/cli.js`, which is
what the npm shim actually runs with node. glob() is for a simple file
check in case bin/ is removed because the npm shims are ignored now.
Workaround for travis issue:
https://github.com/travis-ci/travis-ci/issues/8363
Sometimes `pip3` works, sometimes not:
pyenv: pip3: command not found
The `pip3' command exists in these Python versions:
3.5
3.5.3
Tried these steps to fix the issue:
- add `python: 3.6` to top level of `.travis.yml`
- add `python3` to `addons.apt.packages` level of `.travis.yml`
- `pyenv global system 3.{4,5,6}`
- `pyenv global 3.6`
In all cases the presence or absence of `pip3` was random.
For CI builds unibilium is provided through msys2 packages, and
libtermkey is built from source in third-party from equalsraf/libtermkey.
In Windows we cannot read terminal input from the stdin file descriptor,
instead use libuv's uv_tty API. It should handle key input and encoding.
The UI suspend is not implemented for Windows, because the
SIGSTP/SIGCONT do not exist in windows. Currently this is a NOOP.
Closes#3902Closes#6640
