Breaking Change: __name__ in apps

[dlashua]

In file config/pyscript/apps/appname/__init__.py, __name__ previously was set to "app.appname". With recent changes to master it is now set to "app.appname.__init__".

It broke some of my scripts, though, the fix was simple. This should likely be mentioned in breaking changes.

[craigbarratt]

That's actually a bug in the reload changes. It should still be app.appname.

[dlashua]

Tested this commit. __name__ now works as it did before. The log lines still have __init__ in them (when I'm fairly certain they did not before), but this doesn't cause any issues for me and, aside from some strange Home Assistant "logger:" settings or people who have some script that reads Home Assistant log lines, I can't imagine it causes any issues for anyone else either.

At least for the log line (and I was really okay with it being in __name__ too) I think it makes sense to have __init__ in them to differentiate between a log from the outer level in a file called /apps/someapp/mything.py and a function called mything in a file called /apps/someapp/__init__.py.

[craigbarratt]

The log lines with __init__ were that way in 1.0.0. I decided to get rid of __init__ from the global context names when it's used in the package form for apps and modules. That manes that apps/APP.py and apps/APP/__init__.py now both have the same global context name apps.APP. But only one is loaded (the package form apps/APP/__init__.py takes priority if both are present).

Per your point, a sub file apps/someapp/mything.py will have a global context name of apps.someapp.mything so you can still distinguish it from apps.someapp, which is just for the required file apps/someapp/__init__.py.