jump-to-source command broke, prompts me for TAGS table

[glyph]

This appears to be because poly-ein-mode is on in my notebooks now but I don't know why that is. I only use Jupyter for Python, and this used to be an awesome feature. How do I put it back?

[glyph]

Not exactly sure when this broke, but I'm pretty sure it was between January and February; my current ein:version is "20200210.452"

[glyph]

If I attempt to manually invoke the other branch of the if poly-ein-mode conditonal, I get the message

ein: [info] ein:kernel--handle-shell-reply: No :execute_reply callback for msg_id=(some UUID)

[glyph]

aah, and if I manually instrument execute_reply it tells me __ein_find_source is now undefined, so I guess this functionality just got removed at some point?

[glyph]

Apparently 3c18cda1258a08917f902f0d99e9cd7315abd38d removed ein.py entirely? I'm confused as to how this is even supposed to work.

[dickmao]

Since last Saturday, jump-to-definition is governed by whatever python major mode you're using.

Emacs's built-in python-mode uses etags, which is fairly destitute.

I recommend installing elpy as a suitable python major mode.

[glyph]

I use both Rope and Jedi, but they don't have enough information about what's going on in the notebook to arrive at a correct answer; they need to see between cells to trace name definitions. Does installing elpy fix this somehow?

If this is the desired state of things, there's still some work to do on this issue - presumably it is not the intention to have dead code like ein:pytools-jump-to-source and ein:pytools-jump-to-source-1 which rely on __ein_find_source being defined, still hanging around in the repository.

[dickmao]

they need to see between cells to trace name definitions

elpy leverages jedi or rope and sees as much of the worksheet (but not any scratchsheets) as jedi is programmed to see. If elpy can't do it (and it often cannot), there's no way our erstwhile jerry-built jump-to-def was going to.

presumably it is not the intention to have dead code ...still hanging around

You got it

[glyph]

Thanks for the clean-up!

One other question I have about this is that my own personal setup has a number of different virtual environments, which are normally identified by the placement of the Python file being edited. In the case of a notebook, the correct thing to look at would instead be the virtualenv being used. Where is the appropriate place to ask the kernel about that, so that I can propagate the appropriate source and project location through to Rope and Jedi?

[dickmao]

My guess is you'd configure venvs at the jupyter server level. As in the case of jump-to-def, EIN washes its hands of these highly nontrivial tasks.

[glyph]

I've already configured the venvs there, and I have a naming convention that organizes them in such a way that the kernel name tells me what I need to know.

To ask this question in a much more low-level concrete way, is there a more public-API way to ask this:

(when (functionp 'ein:$kernelspec-name)
        (polymode-with-current-base-buffer
         (lambda () (ein:$kernelspec-name
                     (ein:$kernel-kernelspec (ein:get-kernel--worksheet))))))

[dickmao]

No, (ein:$kernelspec-name (ein:$kernel-kernelspec (ein:get-kernel--worksheet))) is as good as it's going to look.