Univention Bugzilla – Bug 53824
Automatic "name" variable value for Listeners / listener modules created with new listener API always displayed with status=0
Last modified: 2023-02-13 11:41:24 CET
Talking about this: https://docs.software-univention.de/developer-reference-5.0.html#listener:handler If the name of a new listener module is mandatory and it always must be the name of the file without ".py" it would be suggested in the documentation to be set to something like `name = __file__.split('.')[0]` or `name = Path(__file__).stem`
I would vote for removing this completely. I think we can use module.__name__ instead.
(In reply to Florian Best from comment #1) > I would vote for removing this completely. > I think we can use module.__name__ instead. I agree with you. Sounds like a better option at the design level. But, wouldn't that force us to change it at every point where a module name is used? Otherwise whoever loads and uses the module and expects the "name" variable to exist would fail because it is not defined, right?
I think nobody uses the name property. And if we need backwards compatibility, we can simply set it in the UDL via something like `module.__dict__.setdefault('name', module.__name__)`.
(In reply to Florian Best from comment #3) > I think nobody uses the name property. And if we need backwards > compatibility, we can simply set it in the UDL via something like > `module.__dict__.setdefault('name', module.__name__)`. Sounds great to me.
What's the target of this bug? I cannot find a problem description anywhere.
Hello Daniel, I'm new to this. It's just an enhancement suggestion, a cleanup. If the name of the Listener modules is not used in other parts of the code or needs to always be the name of the file it can be automatically generated or removed.
(In reply to Daniel Tröder from comment #5) > What's the target of this bug? I cannot find a problem description anywhere. Each UDL module currently must have the required attribute "name". It's unclear why it must be given *explicitly* instead of being derived *implicitly* from the module file name. [ ] research why it must be given explicitly and document this [ ] Feature-Request to change the API to make "name" obsolete or optional PS: Having "name" <> "$(basename $0)" leads to all kind of strange issues as some code prefers "name" and other code prefers "$0". This complicates debugging and confuses people. Therefore it should be simplified. QED
(In reply to Florian Best from comment #3) > I think nobody uses the name property. And if we need backwards > compatibility, we can simply set it in the UDL via something like > `module.__dict__.setdefault('name', module.__name__)`. The name property is sometimes used in debug output: → ud.debug(ud.LISTENER, ud.ERROR, "%s: something is wrong" % (name,))
The new listener API (package univention.listener) already does create the module level attribute "name" programatically. If you wish to make it optional, just edit univention.listener.handler_configuration.ListenerModuleConfiguration.get_name() to calculate it in case Config.name is unset. BUT: there is already a problem with "univention-directory-listener-ctrl status". Listeners created with the new listener API are always in status 0 / red because univention-directory-listener-ctrl is a shell script that parses the Python file and looks for a "name" entry: module_name=$(sed -rne "s/^name\s*=\s*['\"]([^'\"]+)['\"]\s*(#.*)?$/\1/p;T;q" "$module_file") || rv="$FAIL" So if the word "name" is not in the Python module, you'll have the same problem.
(In reply to Daniel Tröder from comment #9) > The new listener API (package univention.listener) already does create the > module level attribute "name" programatically. If you wish to make it > optional, just edit > univention.listener.handler_configuration.ListenerModuleConfiguration. > get_name() to calculate it in case Config.name is unset. > > BUT: there is already a problem with "univention-directory-listener-ctrl > status". That's exactly the kind of problems I was talking about: We must change UDL and "u-d-l-ctrl" first, so that "name" can become optional. I see no reason to keep that variable "name". It was Bug #48357
My work on UDL module issues <https://git.knut.univention.de/univention/ucs/-/commits/phahn/29420-listener-doc> contains the change - among others.
I added code to set the 'name' automatically from the Python modules file name, in the new listener API, to your branch: [phahn/29420-listener-doc 7ecc5c0181] refactor[UDL]: set UDL module name from module file name
Bug 48357 was the original bug for "listener modules created with new listener API always displayed with status=0". As that bug was resolved with wontfix, and this bug was named the successor, i adapted the title of this bug. Otherwise it is hard to search for this bug. Report of the original bug, so searching can be done more easily: When a listener module created with the new listener API is installed and the u-d-l is restarted the status shown with "univention-directory-listener-ctrl status" is always "0". The listener did however successfully initialize the module, as can be seen in the logfile. The status file in /var/lib/univention-directory-listener/handlers/$NAME does contain a "3", but "univention-directory-listener-ctrl status" still shows a "0".
https://git.knut.univention.de/univention/ucs/-/merge_requests/524
univention/ucs#1363
OK: MR ist merged OK: "name" is now optional OK: various code cleanup and pyupgrade Changelog entry missing.
[5.0-3] a738f61c50 doc(UDL): Changed Listener module API doc/changelog/index.rst | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
OK: changelog entry
UCS 5.0-3 has been released. https://docs.software-univention.de/release-notes/5.0-3/en/ If this error occurs again, please clone this bug.