Macvim: Python 3 scripting broken on macOS Sierra.

Created on 23 Oct 2016  Â·  17Comments  Â·  Source: macvim-dev/macvim

I have a fresh install of macOS Sierra, Python 3.5 installed via official package, Xcode 8.0 (8A218a), and a bunch of tools (but not Vim) installed via Homebrew. Any time there is a :py3 invocation, such as when happens when a .py file is opened using my dotfiles configuration, the Vim process dies a horrible death:

Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

Current thread 0x00007fffb0a333c0 (most recent call first):
Vim: Caught deadly signal ABRT
Vim: Finished.

I have been unable to find a version in the last 10 or so that works. 😭

Most helpful comment

All 17 comments

The latest binary release https://github.com/macvim-dev/macvim/releases/latest supports only Python 3.5.2. It will crash with Python 3.5 and 3.5.1.

Running python3 gives me:

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 26 2016, 10:47:25) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 

Apologies for not being more specific initially; when I meant fresh, I mean, I reinstalled and re-downloaded everything as of 8 hours ago.

Have you tried to set PYTHONHOME and pythonthreedll in your .vimrc? The path may vary.

let $PYTHONHOME=$HOME."/.pyenv/versions/3.5.2"
set pythonthreedll=$HOME/.pyenv/versions/3.5.2/lib/libpython3.5m.dylib

https://github.com/macvim-dev/macvim/wiki/Python-2.x-and-Python-3.x

I do not have a $HOME/.pyenv folder. (I do not use pyenv at all.) The virtual environments I do use (via python3.5 -m venv) do not have dylib artifacts.

Because I'm desperate to not lose productivity, I've also tested my exact dotfiles setup with VimR (a macOS NeoVim shell) without issue. (I prefer MacVim, though, as my keyboard bindings are optimized for it and powerline glyph rendering is much improved.)

I do not have a $HOME/.pyenv folder.

as i said The path may vary. I don't know your environment.

Hmm. I'll try to be more clear. My environment, and steps to reproduce, are exactly:

  • Install a fresh macOS Sierra on a newly formatted partition.
  • Download, run, and install command-line tools via Xcode from the App Store.
  • Homebrew install git, zsh, and a few other unrelated (non-Vim, non-Python) items.
  • Download and install the latest macOS .pkg installer from the official Python site.
  • Install the latest MacVim snapshot from the Github project releases page.
  • Issue the following command in a new, empty window: :py3 print("Hello.")

Alternatively, with a copy of my dotfiles linked in the initial ticket, simply attempt to open any .py file, which invokes python-mode and explodes identically.

The "path might vary", but virtual environments don't even enter into the crash, and of the components involved I'm only using "official" ones. Even if I move my .vim and .vimrc out of the way entirely the crash still happens.

Prior to my full system re-install things were working great up until the last two or three releases. I couldn't upgrade without Python 3 support exploding, so I held off poking the beast until I had less of a crunch time at work. Now, after a full system re-install, I can't get any version to work.

Download and install the latest macOS .pkg installer from the official Python site

Why don't you paste the URL??

It's the one on Python.org, right on the front page. I didn't feel it added anything, but here you go: https://www.python.org/ftp/python/3.5.2/python-3.5.2-macosx10.6.pkg

I can't find any issue with https://www.python.org/ftp/python/3.5.2/python-3.5.2-macosx10.6.pkg with these settings in .vimrc.

let $PYTHONHOME="/Library/Frameworks/Python.framework/Versions/3.5"
set pythonthreedll=/Library/Frameworks/Python.framework/Versions/3.5/lib/libpython3.5m.dylib

Now when running terminal vim I get:

E518: Unknown option: pythonthreedll=/Library/Frameworks/Python.framework/Versions/3.5/lib/libpython3.5m.dylib

But MacVim does, in fact, work. Curious to find out why vimR does not require this setting. I'm reticent to add configuration to my general dotfiles (which are used across a number of machines, platforms, and users) that is incompatible, though. Is there a way I can armour these two directives so they only run within the context of MacVim?

You can use mvim script which is in https://github.com/macvim-dev/macvim/releases/latest MacVim.dmg for "terminal vim".

$ cp /Volumes/MacVim/mvim /usr/local/bin [or somewhere which is in your PATH, the directory should be before /usr/bin in your PATH]
$ ln -s /usr/local/bin/mvim /usr/local/bin/vim
$ vim
It launches Vim binary in MacVim.app, and no errors

Thank you for your assistance with this.

I am aware that the mvim tool exists. That it exists is irrelevant; I can't run mvim over an SSH session to edit a remote file locally, for example, and no MacVim exists on my Linux machines. Other users of my dotfiles aren't using MacVim, either.

One, interestingly, is using a configuration similar to mine but on Yosemite. The two lines you've given don't work for him—this is still an issue. (Same Python .pkg version and everything, but on 10.10.5.) He still gets the failure to find the encodings module.

You also didn't answer the question about being able to armour those lines against non-MacVim use. I would greatly appreciate this, as without it, I can't include those lines in my general, public configurations.

I'm sad to say I may have to stick with VimR simply because it works out of the box without CLI vim-breaking configuration.

if has("macvim")

might work.

Perfect; that works. Edited: Nope, wrapping in that if those lines aren't enabled, even in MacVim, so the problem returns.

@topfloor using my dotfiles on 10.10.5 (freshly updated config, latest MacVim, same Python .pkg installer) continues to have the issue, however.

if has('gui_macvim')
  let $PYTHONHOME="/Library/Frameworks/Python.framework/Versions/3.5"
  set pythonthreedll=/Library/Frameworks/Python.framework/Versions/3.5/lib/libpython3.5m.dylib
endif

Yes, however, that causes brew to install a complete copy of its own build of Python 3, which defeats the purpose of using the official .pkg build.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bmulholland picture bmulholland  Â·  5Comments

kiryph picture kiryph  Â·  4Comments

yamini-krishnamurthy picture yamini-krishnamurthy  Â·  5Comments

mathsaey picture mathsaey  Â·  3Comments

raimue picture raimue  Â·  4Comments