controlnet extension - few compat fixes

[light-and-ray]

In support forge in my extension I've faced external_code no longer has to_processing_unit. And also it produces errors if few units are None

Checklist:

• I have read contributing wiki page
• I have performed a self-review of my own code
• My code follows the style guidelines
• My code passes tests

[huchenlei]

I don't think the changes here are well justified.

• For to_processing_unit, can you share the code which call to_processing_unit?
  • As no code in this repo actually calls to_processing_unit, I think you can implement it in your code, instead of adding the logic here.
• For None filter, can you provide the code path that None could be passed as ControlNet's script args?

[light-and-ray]

@huchenlei this commit: light-and-ray/sd-webui-replacer@27b965c

For any reason sd-webui works fine with dict and convert it "on fly", when forge required to replace all dicts to units right in p.script_args. And second difference between forge and webui: yes, if in p.script_args I've provided only 1 unit, forge didn't work due to NoneType and assert with type checking

[light-and-ray]

I'm looking the code, and I think I've misunderstood and forge doesn't require replace dicts in p.script_args, and it was the same error about NoneType. So the part with to_processing_unit can be removed if you want. But I think it's better to keep it for backward compatibility. But None should be fixed in any way I think, because the webui works with them

[light-and-ray]

But I think it's better to keep it for backward compatibility.

Btw I still need to check is unit enabled, and maybe other fields in future, and I need to have this function. I can write my analog in my code, but why when it's better to have universal conversion function inside external_code module

Before this I had faced only with different lib path and mask which doesn't require special handling. It doesn't a big deal for extension like mine which just uses cn script and nothing else. But why external_code module shouldn't has the same interface with webui by your opinion, when this module was designed like a lib for usage by external extensions? 😐

I don't think the changes here are well justified.

[light-and-ray]

@huchenlei

[huchenlei]

waiting for @lllyasviel's review

[lllyasviel]

hi we are going to close PRs before forge's recent major revision
if we missed some important PRs, please consider reopen (if that is not already on our todo list