Issue 464 logger instead of print

[opsdep]

No description provided.

[aperrin66]

You need to choose one way to configure logging:

• either use the current mechanism with logger attributes defined for each object using nansat.utils.add_logger
• or use a global logging configuration initialized in nansat.__init__

[opsdep]

You need to choose one way to configure logging:

• either use the current mechanism with logger attributes defined for each object using nansat.utils.add_logger
• or use a global logging configuration initialized in nansat.__init__

No we need both of them because the run can be started with nansat usage as standalone (in that case, we need nansat.__init__ ), and as the second case when we run the harvesting, the nansat.utils.add_logger function configures the logger when it is needed.

[aperrin66]

You need to choose one way to configure logging:

• either use the current mechanism with logger attributes defined for each object using nansat.utils.add_logger
• or use a global logging configuration initialized in nansat.__init__

No we need both of them because the run can be started with nansat usage as standalone (in that case, we need nansat.__init__ ), and as the second case when we run the harvesting, the nansat.utils.add_logger function configures the logger when it is needed.

It works exactly the same whether you use nansat alone or with geospaas_harvesting: the "Nansat" logger is created when nansat is imported, then the log level is overridden when add_logger is called (for example when a Nansat object is instantiated).

If you are going to use add_logger, you might as well put the whole logging configuration in there. It will be less confusing than having the configuration in logging.yml and then overriding the log level when add_logger is called.

[opsdep]

@aperrin66 done

[akorosov]

Good!
But I don;t see that logging.config, os.path or yaml is used in __init__.py why did you add that?
If it is not used, can you remove it?

[aperrin66]

You don't need the threadName field, nansat is single-threaded

[aperrin66]

actually is there any need to change the format at all?

[opsdep]

In order to make it in a unified format when we start the process from harvesting, this helps to read the logs easily,all levels of nansat,harvesting and run_container.py MUST have same format of log. Because they are unified when call from each other. Reading logs with different format is difficult. so it is better to keep it. The thread is unknown, or sth like that,it does not matter, let it be.

[aperrin66]

this function is not part of the Nansat class

[opsdep]

but it is in nansat repository.DO you have any other name in your mind?

[aperrin66]

Either leave it as it was or use something like nansat.import_mappers.

Note: nansat refers to the package. Nansat refers to the class.

[opsdep]

Done

[aperrin66]

__name__ already contains the full name of the module (here, it isnansat.mappers.mapper_aapp_l1b), so there is no need to prefix it with "Nansat.".
Same thing for the other mappers.

[opsdep]

yes, you are right! But, when we run it from harvesting, only mapper_aapp_l1b is appear! It is better to keep that in the name of the lagger,isn't it?

[aperrin66]

Then write the full module name (nansat.mappers.mapper_aapp_l1b), that way there is no ambiguity.

[opsdep]

Done