JIT .so's need a unique prefix to avoid colliding with common modules

[stas00]

When JIT is used (DS_BUILD_OPS=0) ds builds ~/.cache/torch_extensions/utils/utils.so and loads it as import utils (that is sys.modules["utils"] points to ~/.cache/torch_extensions/utils/utils.so) which collides with any local utils.py in the end user application, which are very common. This breaks those applications since they no longer can import the local utils.

Please kindly rename the too generic utils to something specific to deepspeed. e.g. deepspeed_utils.

I'm not sure about the other jit modules, I'd say to be safe probably prefix those with deepspeed as well.

This issue doesn't occur if I build the full binary set using DS_BUILD_OPS=1, as then it doesn't use the extension mechanism and ends up in a very clear unique location: deepspeed/ops/utils_op.cpython-38-x86_64-linux-gnu.so

Thank you.

[jeffra]

Oh excellent catch, thank you @stas00. We definitely ran into a similar issue with op naming for pre-built ops but hadn't seen this issue with the JIT compiled ops for some reason. I'll look into this.

[jeffra]

I recall the JIT op name cannot have periods in the name, but we can convert the periods in the absolute name (e.g., https://github.com/microsoft/DeepSpeed/blob/master/op_builder/utils.py#L11-L12) to underscores at JIT build/load time (here: https://github.com/microsoft/DeepSpeed/blob/master/op_builder/builder.py#L203) via self.absolute_name().replace(".", "_"). Feel free to give it a try and submit a PR, the CI uses JIT so it will be able to test this. Otherwise I should be able to try it tomorrow morning or maybe tonight.

[stas00]

Oh, I have no rush here, since I used the workaround of DS_BUILD_OPS=1 - which takes longer to build, but it doesn't have this issue. So I'd be happy to have you solve it when you have the time and resources to do so, as you already know the code base. And thank you, @jeffra!

[stas00]

One workaround solution is to use the TORCH_EXTENSIONS_DIR environment variable #959

[loadams]

This issue should be fixed now due to the use of the envvar mentioned above.