Tests in clu/dsconf_config_test.py uses the lib389 library in /usr/local with pip #6546
Labels
needs triage
The issue will be triaged during scrum
Comments
mmatsuya
added a commit
to mmatsuya/389-ds-base
that referenced
this issue
Jan 27, 2025
The clu test should use the lib389 python module from the installed one on the system, since the command also comes from the system. If PYTHONPATH env variable exists, remove /usr/local path from that. As a result, the path without /usr/local takes a priority in sys.path. If PYTHONPATH doesn't exist, use sys.path and set PYTHONPATH without the /usr/local path. Relates to: 389ds#6546 Author: Masahiro Matsuya Reviewed by: ???
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Description
Tests in dirsrvtests/tests/suites/clu/dsconf_config_test.py added by #5798
was not fail with the old package without the fix. Because the lib389 installed by pip was used for the test.
The clu test should use the system lib389 which was installed on the system.
Because the command binary installed on the system is used for the test.
At least in RHEL9, the default sys.path has /usr/local path, and it has higher priority than
/usr/lib{,64}/python3.x/site-packages which contains the system lib389. And, it can be
changed with PYTHONPATH env variable. By setting PYTHONPATH without /usr/local,
the system lib389 is forcibly used for the test.
Package Version and Platform:
Steps to Reproduce
Steps to reproduce the behavior:
Expected results
dirsrvtests/tests/suites/clu/dsconf_config_test.py fails with the old version.
dirsrvtests/tests/suites/clu/dsconf_config_test.py didn't fail with the new version with the fix for Issue 5798
The text was updated successfully, but these errors were encountered: