samskalicky commented on pull request #18904: URL: https://github.com/apache/incubator-mxnet/pull/18904#issuecomment-679714368
> 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) ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
