One thing that stub brought up on IRC is that he was trying to debug import time problems, etc. Which meant that he couldn't run 'juju debug-code' because that only catches stuff once you get to main().
One option would be for the 'dispatch' that we create to be aware of JUJU_DEBUG_AT, and either
a) Being python code itself
b) Running the src/charm.py under pdb, eg 'python3 -m pdb ./src/charm.py'
I'm not sure the exact syntax we would want, and maybe it would be one of the breakpoints, eg:
juju debug-code --at init
But we should discuss what the possibilities are and how we could help people that want to debug their charms even earlier in the process.
Note that there is always 'juju debug-hooks' and then running './dispatch' by the author. which might be a better answer still for early debugging. But we should discuss it.
One thing that stub brought up on IRC is that he was trying to debug import time problems, etc. Which meant that he couldn't run 'juju debug-code' because that only catches stuff once you get to main().
One option would be for the 'dispatch' that we create to be aware of JUJU_DEBUG_AT, and either a) Being python code itself b) Running the src/charm.py under pdb, eg 'python3 -m pdb ./src/charm.py'
I'm not sure the exact syntax we would want, and maybe it would be one of the breakpoints, eg: juju debug-code --at init
But we should discuss what the possibilities are and how we could help people that want to debug their charms even earlier in the process.
Note that there is always 'juju debug-hooks' and then running './dispatch' by the author. which might be a better answer still for early debugging. But we should discuss it.