[FIX][mail_environment][server_environment] Prevent ImportError.

[yajo]

Fixes #488.

It should fix Travis in OCA/website, like in OCA/website#303 (comment).

@Tecnativa

[petrus-v]

small typo otherwise you get my 👍

[petrus-v]

Could be nice to tell which module is not able to be imported!

suggested:

   _logger.info("ImportError raised while loading env_mail module.")

[yajo]

No need, the logs already say where do error come from, that's implicit by getLogger(__name__)

[petrus-v]

same comment here!

[petrus-v]

In fact the real matter is the missing dependency(sever_environement_files) for server_environment, isn't it?

[yajo]

But AFAICS that addon should be created manually in each environment.

OTOH, the real problem is not controlling the ImportError. That's a bug.

[petrus-v]

ok thanks for those informations! i've never used this module :) I was reading that on the history on other PR...

[yajo]

Me neither, but this bug is messing up other repos' bots... 😆

[dreispt]

@yajo sorry for nagging, but you shouldn't merge your own PRs.

[DarioLodeiros]

the hard import: https://github.com/OCA/server-tools/blob/8.0/server_environment/serv_config.py#L32
is the problem, when you run Odoo, this import is a real problem becouse it causes boot failure even if it is not installed.
I think that isn't enought this fix... ¿?

[moylop260]

What about use the new standard of ImportError to know the exactly package with the error?

https://github.com/OCA/maintainer-tools/blob/master/CONTRIBUTING.md#importerror

try:
    import external_dependency_python_N
    import external_dependency_python_M
    EXTERNAL_DEPENDENCY_BINARY_N_PATH = tools.find_in_path('external_dependency_binary_N')
    EXTERNAL_DEPENDENCY_BINARY_M_PATH = tools.find_in_path('external_dependency_binary_M')
except (ImportError, IOError) as err:
    _logger.debug(err)

[yajo]

Hi @dreispt, this had already 3x👍; isn't that enough to merge? (Sorry if I missed something, I've been PSC for not so long).

@DarioLodeiros, I tried that. The problem is that if you catch the ImportError but still continue executing the whole module, another exception would be probably raised because the module was not loaded properly. I decided to catch the exception at a higher level to abort loading the rest of the file(s) if the import fails. After all, this is a quick patch for an addon that I don't use but breaks my environment, its actual developers should do a better patch if they need it 😉.

@moylop260 If I understand fine, you mean that you want to get the ImportError traceback. Actually I'm using a feature of the logging module, the exc_info=True flag, which outputs current exception traceback automatically appended to the message. I use an INFO to display the import error, but leave the traceback at DEBUG level. Also, all imports with possible failures are grouped, so what exactly are you missing here? 😕

[sbidoul]

@yajo why was this module suddenly creating problems? It had not been causing any problem for years.

[yajo]

No idea, but it happened.

[DarioLodeiros]

The source of the problem is the hard import of a module that does not exist... server_environment_files
If you clone the repository, actually it break the enviroment... i think that thisn't admissible... ¿?¿

[yajo]

Indeed. I mean I don't know how come it was not failing before 😁

[sbidoul]

mail_environment was never auto imported (unless installed in a database) because it has no static directory. So there is no reason it would start failing suddenty. @yajo I could not find the travis failure you mention.

#617 created some noise because that module had a static directory causing it to be auto imported. But that is fixed in #676. So please guys do not rush at the risk of doing more harm than good.

[yajo]

Nice to know that, although could you please detail what did I harm here?