[EIN] Cannot open load file: No such file or directory, ein-multilang

[korayal]

Looks like ein-multilang was replaced in favor of ein:polymode a long while ago.

Recently that module has been completely removed, so any mention of ein:notebook-multilang-mode in it's Spacemacs layer is failing.

ein-company is also removed in favor of the native completion available by the major mode.

[duianto]

Confirmed.

With the ipython-notebook layer installed and the packages updated.

A *Warnings* buffer opens on startup with the message:

Error (use-package): ein/:config: Cannot open load file: No such file or directory, ein-multilang

Windows 1903

#### System Info :computer:
- OS: windows-nt
- Emacs: 26.3
- Spacemacs: 0.300.0
- Spacemacs branch: develop (rev. 7f92a4388)
- Graphic display: t
- Distribution: spacemacs
- Editing style: vim
- Completion: helm
- Layers:
```elisp
(autohotkey auto-completion command-log emacs-lisp git github helm imenu-list ipython-notebook markdown multiple-cursors org
            (shell :variables shell-default-shell 'shell shell-default-height 30 shell-default-position 'bottom)
            spell-checking syntax-checking treemacs version-control)
```
- System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS THREADS LCMS2

[et2010]

ein-multilang has been removed:

https://github.com/millejoh/emacs-ipython-notebook/commit/5de0c8b8a4dfc94a5f02aadd88fdeeca0945e7aa

[zjp]

The only reference to ein-multilang itself in Spacemacs is in layers/+lang/ipython-notebook/packages.el and the string multilang only appears as part of ein:notebook-multilang-mode-map under ein:notebook-multilang-mode

Unfortunately it seems that it's not quite as simple as just nixing all the references to multilang and leaving notebook-mode/notebook-mode-map behind, as Spacemacs complains that ein:notebook-mode-map is void.

Luckily, though, the problem looks contained in one file.

[smile13241324]

@korayal I have merged your PR, when this solves your problem please close the issue.

[korayal]

@smile13241324 thanks!

[zjp]

@korayal Thanks for tackling that! EIN is critical to me.

[mjsteinbaugh]

I came across this issue today, and switching to the develop branch (0.300.0) fixes the ein-multilang error:

cd ~/.emacs.d || exit 1
git fetch --all
git checkout -b develop origin/develop
git pull
emacs

[dickmao]

Hello, I am the primary developer of EIN.

My longstanding impression has been that the EIN Spacemacs layer has effectively zero chance of working given the volume and severity of upstream changes. Moreover, there appears to be no regression testing.

My inclination is to abolish the Spacemacs layer, and have Spacemacs users install EIN in the conventional way. I imagine some nice vim-style keybindings are lost in return for a reasonable semblance of functionality.

I notice the EIN Doom module is also constantly playing "catch-up" https://github.com/hlissner/doom-emacs/issues/2545.

I don't believe such "catch-up" strategies are viable, but I am not one to impose that belief especially as Doom/Spacemacs community members appear to be willing to do this work.

[dickmao]

A third alternative (first is status quo, second is abolish) is to bring the layer upstream, test it there and ensure our tests pass. This is the most work (for me). It would help to know if any other upstream packages seamlessly insert a spacemacs layer upon package-install when (featurep 'core-spacemacs) is true.

[dickmao]

cf. #13336

[smile13241324]

I am not sure how to improve the situation except freezing the respective package. In Spacemacs terms we do not do regression testing for single packages but only for the core aka our packages.

If you need to introduce many breaking changes in the near future please go ahead, we will freeze the package and wait till the api is stable again.

Can you ping us when the big refactoring is done? We could then adapt the layer respectively.

On Sun, 1 Mar 2020, 09:43 dickmao, notifications@github.com wrote:

cf. #13336 https://github.com/syl20bnr/spacemacs/pull/13336

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/syl20bnr/spacemacs/issues/13243?email_source=notifications&email_token=AEKCTAGPTXBYWAO6ZUKR77DRFIN3FA5CNFSM4KQYQGF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMY2KA#issuecomment-593071400, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEKCTAFWAO6QUXQ7ECRIN53RFIN3FANCNFSM4KQYQGFQ .

[dickmao]

Having worked on #13336 it became clear leader-key bindings are effectively everything. Not having them would defeat the purpose of Spacemacs and Doom.

Doom pins which I am generally opposed to as the sooner something breaks, the sooner it can be fixed. My opinion is not widely shared by industry.

I have no issue with this "best efforts" status quo. It's easily better than nothing, and practically speaking, better than having to coordinate with upstream authors. It is a little unnerving though to see how non-experts patch breaking changes.

[smile13241324]

Yep thats open source but by and large it works normally, till something breaks :). Anyway lets discuss with the other maintainers whether we freeze the package or just muddle through like we did before.

[smile13241324]

Looks like it will be pinning.

[korayal]

personally I prefer using the latest version of the upstream package. If I wanted to play safe, I'd stay on the master branch (there, I could agree on pinning). so if there's going to be pinning, I'll probably switch to a local version of the layer.

I don't think there's much problem with regards to the ein package. If I'm not missing anything, ipython-notebook layer of Spacemacs just changes the keybindings for the package to conform Core Pillars.