It’s good that you question it, I can see how it may seem unnecessary, especially considering plug-ins that import any host-bound modules are being discarded regardless anyway, because they fail to get imported.
hosts attribute is one of the optional ways you can associate a registered plug-in with data, similar to families; one distinguishes between the environment and the other between content. Whether you need to make the distinction in your collection of plug-ins depends on how your write and organise them.
You can, for example, register plug-ins only relevant to a particular host, in which case a plug-in of an unsupported host may never be registered in the first place and thus not be affected by the filtering mechanism. But if you do register one plug-in with support for one host, and one with support for another, then the
hosts attribute can help you distinguish between which plug-in operates in which host.
There are a few other ways planned for future releases.
- Filter by version
- Filter by OS
families = ["myFamily", "myFamily.childA"]
hosts = ["hostA", "hostB"]
version = "2.4.1"
oss = ["win", "osx"]
And like with
families, depending on the complexity and size of your plug-in collection, and how you organise them, all or none of these may be necessary.
I think with the new defaults for
families this will make more sense as being optional. If you can’t find a need for them right away, don’t fret. And if the time comes when you do need to make this distinction, you can.
On another note, with regards to rolling your own filtering mechanism, e.g.
if "maya" in sys.executable:
# do Maya things
if "nt" in os.name:
# do Windows things in Maya
Consider still making note of which hosts and families are supported via the corresponding attributes for the purpose of communication.
In a lengthy plug-in, it might get difficult for another developer, or your future self, to figure out which hosts a plug-in supports, especially when a host-library isn’t being directly imported at the top of the file or when said library isn’t one we recognise (like one from Clarisse or Cinema4D).
Finally, by having plug-ins share a common ground for supported hosts, families, OS’s and versions opens up doors for when sharing is more common and filtering more important.
For example, you may be looking for a Maya plug-in, or a plug-in related to OSX file permissions or a later version of a plug-in you already have. These attributes make this possible and I would make it a habit of at least filling them out, if not only for the purpose of future-proofing them.