It’s not an issue, just a warning to future deploy-ng user as it’s an easy to fall in trap
If your application has the following structure :
my_app/
__init__.py
something.py
my_app.py
my_app.y is importing code from my_app.something package.
When you manually run your application it will work without problem, however when generating a binary using deploy-ng, it’s won’t work at all, and you will have something like
ImportError: No module named my_app.something
in the log.
This is caused by the fact that deploy-ng is actually importing my_app.py as a module and so the package my_app is shadowed by the main script.
TL;DR: Don’t use the same name for your main script and application package
This is a little odd. I thought deploy-ng would be packaging the main module under the name of __main__ (which is also necessary for the __name__ == '__main__' check to work).
Could it be that my_app.py is also being picked up unnecessarily, despite not being imported by your main code, due to an overly aggressive include pattern? Or perhaps the modulefinder needs to be ignoring my_app.py from consideration when scanning the import my_app inside my_app.py, since a self-import is obviously bogus.
That said, it is generally fairly wise not to give a package and a module the same name; anything else in this directory that has an import my_app would also be ambiguous.
