@ekzhu , I think the pattern that @jackgerrits adopted for code executors and tools was to move the imports inside the classes and throw a runtime error if the dependencies are missing. I did something similar in #4423. The main difference is that I still kept the imports in the top of the module but sued a module variable to track whether the dependencies are available and delay the exception to runtime. The only drawback is having some imports done twice because pyright complains the varaibles may be unbound (even with the variable check in the code).

If that pattern is acceptable then I can update the models and web surfer in the same way.

BTW, happy thanksgiving!

I think previously we want to export classes from submodule directly because the API documentation site shows a nested structure so it was easier to navigate the docs. However we have found that a flattened structure is better, see the issue #4377. Once the structure is flattened, having the full submodule path for class is actually better because now the public utils related to the classes are grouped together with the class as well.