Unsigned code prevents use on modern OS X

[johnwhitington]

Upon installing on OS X, and trying to use Vim:

"~/repos/cpdf-source/cpdfcommand.ml" 4665L, 166889C
Error detected while processing /Users/john/.opam/4.11.1/share/merlin/vim/autoload/merlin.vim:
line   86:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/john/.opam/4.11.1/share/merlin/vim/autoload/merlin.py", line 1, in <module>
    import subprocess
  File "/usr/local/Cellar/python@2/2.7.16_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 72, in
 <module>
    import select
ImportError: dlopen(/usr/local/Cellar/python@2/2.7.16_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/sel
ect.so, 0x0002): code signature in (/usr/local/Cellar/python@2/2.7.16_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7
/lib-dynload/select.so) not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least 
ad-hoc signed.
Error detected while processing function merlin#Register[136]..merlin#LoadProject:
line    2:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'merlin' is not defined
Press ENTER or type command to continue

[gasche]

I looked more at the error message. It looks like one of the packages of your system does not comply with OSX code-signing requirements, so there is an error when Vim tries to dynamically load Merlin as a Python plugin. I know nothing of OSX dynamic-library security measures, but the error message appears to suggest that it is the Python installation which is at fault, not Vim or Merlin.

More precisely, the issue seems to be a lack of signature for /usr/local/Cellar/python@2/2.7.16_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /lib-dynload/select.so. This path might suggest that it comes from a user-installed Python package, rather than some officially-distributed implementation of python. Is it possible that the problem comes from there? (If that was the issue, then I guess that other Vim plugins would fail for the same reason. But I know nothing about Vim plugins and which of them use this particular API.)

[johnwhitington]

It looks like something is choosing brew-installed Python 2.7 over the system Apple-supplied 2.7, which presumably is properly signed. The system one is first on my path, though:

gorge:repos john$ which python
/usr/local/bin/python

[gasche]

Note: Merlin's code to detect the Python version is at https://github.com/ocaml/merlin/blob/0c9d95d/vim/merlin/autoload/merlin.vim#L3-L21 . I don't see anything that would explain the issue there, but then I don't know how vim functions has('python3') and has('python)are implemented. It seems to try python3 first (apparently not found in your case), then callpython` in the PATH. Odd.

[johnwhitington]

Thanks. Particularly odd since python3 is on OS X by default:

gorge:repos john$ which python3
/Library/Frameworks/Python.framework/Versions/3.8/bin/python3

[gasche]

I see similar-looking issues reported on other (neo)vim plugins, see for example ycm-core/YouCompleteMe#3216, and people there (don't explain what the issue is but) report that using Homebrew's version of vim (rather than the OSX-native vim, if I understand correctly?) fixed the issue. (Or it may be that homebrew has 8.1 and the other package at the time was 8.0, and 8.1 fixes the issue.)