> So that does mean a workflow where people pip install mxnet and then build > their own operator on top will not be possible? They will still have to > maintain a fork, although the separation is a bit clearer now? > > I think we can draw a lot of benefits if one does not have to compile mxnet > itself as that would allow us to start working with optional features as > separately disturbed and maintained components. Right now there seems to be a > very tight coupling and I understand where it comes from, but the question is > whether we see the vision as valuable and if we can work out a plan that > would enable that way. I understand that the current build system is not > built with that in mind, but mxnet 2.0 would give us the opportunity to break > some things to pave the path.
Yes, external operators will not be possible this way. If you want to not build MXNet you can use [C++ Custom Ops](https://github.com/apache/incubator-mxnet/tree/master/example/extensions/lib_custom_op) (but not external ops) -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-mxnet/pull/18904#issuecomment-679714368
