[2.0.alpha] fixed backend_opts to be empty dictionary instead of None

[samskalicky]

Description

Fixes #19811

[mxnet-bot]

Hey @samskalicky , Thanks for submitting the PR
All tests are already queued to run once. If tests fail, you can trigger one or more tests again with the following commands:

• To trigger all jobs: @mxnet-bot run ci [all]
• To trigger specific jobs: @mxnet-bot run ci [job1, job2]

---

CI supported jobs: [centos-cpu, unix-cpu, clang, website, unix-gpu, edge, windows-cpu, sanity, miscellaneous, centos-gpu, windows-gpu]

---

Note:
Only following 3 categories can trigger CI :PR Author, MXNet Committer, Jenkins Admin.
All CI tests must pass before the PR can be merged.

[leezu]

Thank you! Could you please add a test? It looks like this was completely untested?

[samskalicky]

Thank you! Could you please add a test? It looks like this was completely untested?

Looking at the flow, it seems to only happen when calling optimize_for twice. After each call the backend and backend_opts are cleared:
https://github.com/apache/incubator-mxnet/blob/49edbfc82cb0ce3b823051e1acc26388bc79686c/python/mxnet/gluon/block.py#L1398-L1401

And then the "clearing" sets the backend_opts to None. So on the 2nd call, if the user does not provide any options it would run into this scenario (where backend_opts is None). In the lib_subgraph extensions example we call optimize_for once to partition, and then a 2nd time to run a graph pass:
https://github.com/apache/incubator-mxnet/blob/49edbfc82cb0ce3b823051e1acc26388bc79686c/example/extensions/lib_subgraph/test_subgraph.py#L65-L78

But in the unittests, we only use the default subgraph backends:
https://github.com/apache/incubator-mxnet/blob/49edbfc82cb0ce3b823051e1acc26388bc79686c/tests/python/unittest/test_subgraph_op.py#L267

So theres no way to duplicate exactly what is being done in the example. But, we do build the lib_subgraph library in the CMakeLists.txt:
https://github.com/apache/incubator-mxnet/blob/49edbfc82cb0ce3b823051e1acc26388bc79686c/CMakeLists.txt#L814

So we could add a test in unittests to use this library. But I think we decided not to do this in the past since people were running the unittests on pip wheels that didnt have the libraries packaged into the wheel. Thoughts?

[leezu]

But I think we decided not to do this in the past since people were running the unittests on pip wheels that didnt have the libraries packaged into the wheel. Thoughts?

The CI does not use wheels for most pipelines AFAIK. You can just add a separate test folder and execute it manually in one of the CI pipelines?

[leezu]

@mxnet-bot run ci [unix-cpu, windows-cpu, windows-gpu]

[mxnet-bot]

Jenkins CI successfully triggered : [windows-gpu, windows-cpu, unix-cpu]

[samskalicky]

The CI does not use wheels for most pipelines AFAIK. You can just add a separate test folder and execute it manually in one of the CI pipelines?

I found a file test_extensions.py in tests/python/unittest and added the relevant code from the example so that it will be tested in the CI. Thanks for the discussion!