Debug step-in does not work at all, neither do other module break points

pip list | grep -e ‘lab’ -e ‘xeus’
jupyterlab 4.0.9
jupyterlab_pygments 0.3.0
jupyterlab_server 2.25.2
jupyterlab-widgets 3.0.9
xeus-python 0.15.11
xeus-python-shell 0.5.0

Spent the better part of yesterday following all sorts of different directions for debugging. Here is the use case:


class Symbol:
   def new(self ,name):


class SymbolTest(Symbol):
  def test_new_symbol(self):
 ->   symbol_id ="TestSymbol")
    if symbol_id != 3:
      print(f"{L.fqmn()} new symbol_id is not 3.")
      return False
    return True
  1. I set the break point at the line with the arrow, and execute the test. Execution stops at the break point. All good so far.
  2. On the GUI I press the little downarrow step-in button. No dice. It steps over.

I followed some directions to install Xeus. I followed some directions to save the files as executable scripts. I tried setting both modules to the same kernel. No dice. I tried setting a break point in Symbol::new(), and it is ignored.

How can I make the debugger work? It would save a lot of time to have a working debugger. There is not much code in the top module, so it is not really helpful to only be able to set break points there.

Xeus does issue a frozen modules warning. My understanding is that is for system modules, not my own modules. I set the environment variable to squelch that message. Could ‘frozen modules’ be the problem? – turning off the frozen modules feature did not help.

After some thought and experimentation, an AI developed by OpenAI, suggested a successful workaround for this problem. Instead of doing from Symbol import Symbol to bring in the class that is being tested, use the magic command %run ./Symbol.ipynb

I’ve noticed that in addition, the kernel for the module to be stepped into must be set to be the same kernel as that being used for the module to be stepped from. A programmer can tell when they are the same kernel because the debug numbers will appear in both tabs simultaneously when the debug button is pushed.

Then when the step-in button pushed, the code line highlighting will disappear. The programmer must know which notebook tab to go to. At the target notebook tab there will initially be no highlighting. Hit ‘step’ to go to the next line of the called function, and then the highlighting will appear on that next line.

I sure hope someone knows a better way to do this. I’m hopping for a setting checkbox or something that causes it all to work.

LOL, after using it like this for about 30 minutes it has decided it doesn’t want to stop at breakpoints anymore. I restarted the kernel, I restated the server, I even cleared the browser cookies - nothing can convince it that it wants to stop at break points. This is even break points in the same module.

Is there something whacky with this installation, or is the Jupyter Lab debugger unstable?