that behaviour hasn't changed between 3.0 and 3.1. It was always the case that the deep_reload_include option restricts deep reloading to only those packages.
I've been trying to reproduce the problem of reloading failing after a number of attempts, and that of functions not working until the first reload, and have been unable to
However, while working on this I did find that if I had a module (A) that was imported by another module (B) and in the modules list in the config I had B followed by A then when I first started A would get imported (by A) and then reloaded by pyxll.
Is it possible that there have been some other code changes or config changes that were made around the same time as moving from 3.0 to 3.1? It could be something like what I described above that should be harmless, but is causing a problem when deep_reload is enabled.
I have fixed this import/reload issue in the latest beta build (which you can download from https://beta.pyxll.com
). I was also thinking about the problems with reloading packages like numpy and pandas. In 3.0 any c extension is ignored when reloading, and now I have made that more conservative by not reloading any package that contains a c extension. This means that packages like numpy and pandas will now be automatically excluded from being reloaded.
Reloading Python modules is tricky. The deep reload feature works by building a dependency graph of imported modules and reloads them from the bottom up, but if there are circular dependencies or any more complex dependencies then it may not work. It's really there for convenience while developing code, and so restricting it to code you're working on is a good way to avoid those problems.
p.s. as you mention changing other users' configs, did you know you can centralise your users' configs by using an external config file? See the 'external_config' option:https://www.pyxll.com/docs/userguide/config.html#pyxll-settings