Allow for operator.py to live in reactive interface repositories w/out being loaded by charms.reactive.bus discovery

[afreiberger]

Would it be possible to re-add a blacklist for discovery on the name "operator.py" within the context of loading hooks/relations from interface:xyz repositories? (I see blacklist was removed during change #224

Most interface layers likely only have handlers in files name provides.py and requires.py as a standard, but understandable that all *.py are worthy of checking for reactive state handlers.

To give an idea, I've added operator.py to the interface-prometheus reactive interface repository and broken all reactive charms that use interface:prometheus.

Here's the traceback I'm getting while trying to charm build lp:charm-prometheus2 https://pastebin.ubuntu.com/p/M4PM39HsnV/

Here is the interface repository: https://git.launchpad.net/interface-prometheus/tree/

We were hoping that we could put common Operator framework interface libraries into the layer-index listed repos used for reactive so that ownership of the interface handling code doesn't have to change or become one more repository to manage for that team and require publishing of python packages. Here is the layer-index I'm talking about as the go-to source for where pre-existing code for interfaces live: https://juju.github.io/layer-index/

[johnsca]

You can add the following to the layer's interface.yaml:

ignore:
  - operator.py

That will make any charm built with that layer ignore that file from the layer so it won't be included in the built charm. You can also then include setup.py or whatever other files you need to support the operator framework portions alongside the reactive portions.

Thinking toward the future, I had been wondering if there might be a way we could make it easier for and encourage charm authors to only do interfaces in the new framework style going forward, rather than having to maintain both versions. Some kind of shim for using them in reactive charms, or even pulling in the new framework entirely and running them in parallel? That might prove more effort than it's worth, though, I suppose, but it really seems like interface code is going to be a big sticking point for getting people to commit fully to the new framework.