Skip to content

[Feature]: Some simple features to add (all can be done in one PR) #58

@emmuhamm

Description

@emmuhamm

Description

Fix calling of loggers

Linked from #46

We also need one where a warning is thrown when this happens:

log = get_logger("name", stream_handler = True)

new_log = get_logger("name") # Will grab the correct logger

new_log_extra = get_logger("name", stream_handler=True, rich_handler=True) # this will get the correct logger, but not add the rich handler. This should be checked when performing this function and be made explicit..


UPDATE 25/03/26: After further testing, the second line does not work lmao. I think this is the intended behaviour so no fix required.

For context, we want people to be absolutely certain what daq logger with what handler they are calling. Even though these are singletons, it should ideally only be called once.

If they really need the same handler, they really should look into using logger inheritance instead.

Add safe environment injector

Better handling of the variable names in ERS. It shouldn't affect anything major right now since python is quite well behaved in terms of env variables, but to be safe ykno.

ers_envs = {
    "DUNEDAQ_ERS_WARNING" : "erstrace,throttle,lstdout",
    "DUNEDAQ_ERS_INFO" : "erstrace,throttle,lstdout",
    "DUNEDAQ_ERS_FATAL" : "erstrace,lstdout",
    "DUNEDAQ_ERS_ERROR" : (
            "erstrace,"
            "throttle,"
            "lstdout,"
            "protobufstream(monkafka.cern.ch:30092)"
        )
}

def obtain_original_envs(envs: dict) -> dict: 
    return {
        key: os.environ.get(key)
        for key in envs
    }

def restore_original_envs(original:dict) -> None: 
    for var_name, original_value in original.items():
        if original_value is None:
            os.environ.pop(var_name, None)
        else:
            os.environ[var_name] = original_value

See 311a4e1 in #47

Might be easier to discuss here rather than GitHub.


Discussion with Pawel:

Regarding the os.environ variable, my broad opinion is that I'd like to defer this to #46 instead of the current one that introduces new handlers (#37)

While the fix itself is easy, I decided to do some tests and find that running the logging demonstrator as is does not change the shell's current environments. For example:
export DUNEDAQ_ERS_WARNING="SOMETHING"
echo $DUNEDAQ_ERS_WARNING # 'SOMETHING'
daqpytools-logging-demonstrator -r --handlertypes
echo $DUNEDAQ_ERS_WARNING # 'SOMETHING'

From my readings, in some docs here it says that os.environ only affects the local python shell, and it doesn't 'leak' out into the bash environments which is useful in this case. This is quite nice for us, so I think it would be fine as is in #37.

Saying that, I do agree that this is a good change. I propose therefore to put it in #46, where I have a pretty significant refactor of logging_demonstrator anyway. Seems like the perfect place to put it (and also saves me from annoying rebases lmao). Plus, as the docs say it should be safe enough as is, and I would expect #46 to come in shortly anyway.

Potential impact radius

Small/Isolated

Reason for change

No response

Suggested implementations

No response

Testing suggestions

No response

Anything else?

No response

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions