No one has claimed the proposed alternatives are ‘shielded from breakages’. Frankly, anyone who has carefully read this, now long-winded, thread has gathered that the alternatives definitely have disadvantages, not the least being that they behave like ‘partial overlays’.
I refrained from marking any of the alternatives as being the “solution” because the choice will be based on one’s own needs. The one I chose may not be best for others.
NOTE: At the request of @tboyce1, I’ve marked this post as a “Solution” (mostly to help locate it in this long thread). Please understand that this post is less of an ultimate solution and more of an overview of the currently available options to get your custom component working with 0.89.
Three ways to get your custom component to work in 0.89
I think the readers of this lengthy thread have gained enough insight to judge the merits of each approach. For those who have arrived late, here’s a summary. I’ll be using the MQTT platform in the examples (Paulus used Hue in his examples) only because I use it extensively and it happens to be one of the more comprehensive ones, supporting many different components (and even its own flavor of automation).
Replacement
This is the approach recommended by Paulus in his blog post (and PR).
If you have modified MQTT climate.py, copy it to custom_components/mqtt and all other unmodified MQTT components and related resources. Why? Because it only takes the presence of one MQTT component (modified or not) in custom_components/mqtt for Home Assistant to exclusively use this directory for finding all other MQTT components. In other words, it stops using the stock components/mqtt directory.
The reported advantage of this approach is it is self-contained and more insulated from underlying changes. It also opens the door to future improvements such as packages. The MQTT platform can become modular, support versioning, and be upgraded independently (within reason) of the core system.
The one caveat of a full replacement (in its current form in 0.89) is that it may encompass more than one might expect. MQTT also offers its own automation service. Therefore if you wish to use a service like mqtt.publish you must also copy its directory as well. Otherwise, Home Assistant will fail to find it because as mentioned earlier, its search-path for MQTT resources will be custom-components/mqtt.
Derivation
This approach uses a new platform derived from the desired platform. Place the modified MQTT components into a new directory (your choice of name) like custom_components/my_mqtt. In configuration.yaml, set the affected entities to use platform: my_mqtt.
The primary advantage of this approach is simplicity. If your custom component is used by many novices, this approach offers the easiest installation instructions. Because it is derived from the MQTT platform (and simply assumes a different name), it continues to share all resources with the stock version of MQTT. Home Assistant continues to use the stock components/mqtt directory for all MQTT-related resources.
This approach has several disadvantages. It behaves like the ‘partial overlays’ allowed in pre-0.88 versions so it lacks the ‘insulation’ offered by full replacement. It also creates a potential, future ‘conversion task’ in the event you ever wish to switch from using the custom component to the stock version (i.e. switch from platform: my_mqtt to platform: mqtt). If your entities have a unique_id then they are uniquely registered in the entity registry (if they don’t then this task doesn’t apply to you). If you change a registered entity’s platform, Home Assistant will re-register it as a different entity. For example, climate.thermostat will be re-registered as climate.thermostat_2 (effectively it’s a duplicate with the only difference being the platform it uses). Now you have a conversion task on hand and must edit the entity registry and clean up the duplicates (otherwise your Lovelace UI will be missing entities). There’s a way to simplify this task … but that’s for another post.
Redirection
This approach is sort of a hybrid of the two previous approaches. The advantage it has over derivation is the platform name remains unchanged so you’ll never have the potential conversion task. The advantage it has over full replacement is that, in effect, it doesn’t require you to make a true, full copy of the stock version (more about that in a moment).
Its disadvantage is the same as with derivation, it behaves like ‘partial overlays’ so it remains vulnerable to changes made in the underlying system.
Place the modified MQTT components into custom_components/mqtt. For the unmodified components you can create a placeholder or ‘redirection’ file containing a single line of code telling Home Assistant to refer back to the stock version of the component. For example, create
/custom_components/automation/mqtt.py containing a single line:
from homeassistant.components.automation.mqtt import *
This obviates the need to copy everything related to mqtt.automation. Other MQTT components can be handled in a similar fashion or just copy them over completely. You decide how much, or how little, is to be handled by placeholder/redirection files.
One other disadvantage of this approach is, quite simply, you have to create each redirection file. It may make sense in the case of mqtt.automation (avoids having to copy all of that) but maybe less so for more self-contained components like light.py, sensor.py, etc.
The installation instructions for this approach have the potential to be more complex than either ‘full replacement’ or ‘derivation’ (especially more complex than derivation). That might be factor if you intend to share your custom component with novices.