-
Notifications
You must be signed in to change notification settings - Fork 126
Add wrapper for ldap_connect #534
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
83ac741
to
1a21801
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late review!
The code looks good!
One minor suggestion, though - I think we need to add an entry to the docs. Somewhere here maybe? https://github.com/python-ldap/python-ldap/blob/30fe146e6c8e881a2db2a3f6b60fb6201bf6a534/Doc/reference/ldap.rst
But it can be done later, I think. So ack from me.
Hmm, there's a failure in the added test though on some of the envs (but not all of them). Weird... |
Lib/ldap/ldapobject.py
Outdated
def connect(self): | ||
""" | ||
connect() -> None | ||
Establishes LDAP connection if needed. | ||
""" | ||
if _ldap.VENDOR_VERSION >= 20500: | ||
return self._ldap_call(self._l.connect) | ||
raise NotImplementedError |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to conditionally define the method. That way it's is possible to introspect the connection object and detect whether libldap supports the call.
def connect(self): | |
""" | |
connect() -> None | |
Establishes LDAP connection if needed. | |
""" | |
if _ldap.VENDOR_VERSION >= 20500: | |
return self._ldap_call(self._l.connect) | |
raise NotImplementedError | |
if _ldap.VENDOR_VERSION >= 20500: | |
def connect(self): | |
""" | |
connect() -> None | |
Establishes LDAP connection if needed. | |
""" | |
return self._ldap_call(self._l.connect) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that a preference thing? From my point of view, pyhon-ldap's external surface shouldn't morph this way and throwing an exception sounds more appropriate.
I was tempted to use the actual libldap version if we had access to runtime libldap version banging about already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep in mind that _ldap.VENDOR_VERSION
is a compile time constant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep in mind that
_ldap.VENDOR_VERSION
is a compile time constant.
Yes, that is correct. The function won't be available if python-ldap is compiled with an older version of OpenLDAP. A newer runtime version won't enable the feature.
Is that a preference thing? From my point of view, pyhon-ldap's external surface shouldn't morph this way and throwing an exception sounds more appropriate.
Do you have a better proposal how users can detect the presence of the feature up front? I don't want users to hard-code a version check. You could add ldap.HAVE_CONNECT
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they can't handle a NotImplementedException, they can still read ldap.VENDOR_VERSION
?
I agree we need to figure out a general way of exposing new libldap interfaces that always exist (unlike ldap_init_fd
) without yet more HAVE_*
flags that are compile-time, but not runtime anyway.
AFAIK that's usually done by upping a hard dependency but I take it you're against declaring a dependency on 2.5+ just yet (in python-ldap 3.5.0 that is)? That would be the easiest approach and one I'd prefer. We still support 3.4 anyway and that's fine for some (defined) time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, what I'm suggesting is "if you need ldapobject.connect(), you should depend on python-ldap 3.5" and "python-ldap 3.5 will depend on libldap 2.5+".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the alternative... (see latest push)
1a21801
to
60c91de
Compare
059f0d7
to
3b32e9c
Compare
In my opinion and experience, we should be very careful and mindful with libldap version requirements. A Python package cannot declare a minimum version of an external dependency. If we bump the minimum version, then we may break people's setup. python-ldap should stay compatible with Alpine, CentOS 7, Debian old stable, openSUSE Leap, and oldest Ubuntu LTS release. A lot of them are still on OpenLDAP 2.4, see https://repology.org/project/openldap/versions . We may consider requiring OpenLDAP 2.5, when CentOS Stream 8 and Debian 11 have reached EOL (2026 for Debian). |
Amazon Linux 2023 (just released) still uses OpenLDAP 2.4, sadly. |
3b32e9c
to
f53793b
Compare
f53793b
to
b2e20e5
Compare
b2e20e5
to
51a8bd1
Compare
Not sure I want to do runtime libldap detection, but the new commits do just that. I still think it's better to decide at compile time and have only one ifdef for NotImplementedError/the actual implementation. |
No description provided.