Open steffen-kiess opened 8 months ago
I would be very reluctant on adding this as MIT krb5 for Windows supports a widely different set of APIs than what their Linux releases do. We also don't ship any wheels for Windows right now so for an end user to install this library they would require the dlls to be present anyway to build the module on Windows negating the need to search for the dll at runtime.
Ultimately before we could look into this we would need to
Add testing in CI for Windows, or at least to an extent where we can build and import the module at least
I might look into this at some point if I can find the time.
Determine if we want to create pre-built wheels for Windows
I think this might be a good idea.
Determine if we want to ship the krb5 dlls inside our wheel or do what python-gssapi does and just have them as a dependency
I think doing the same thing as python-gssapi would be a good idea. Reasons for that are that:
pykrb5
and python-gssapi
are used (or pykrb5
and some other library which depends on libkrb5
) it would be good if they end up using the same instance of libkrb5
so that e.g. MEMORY:
ccaches are shared. If pykrb5
brings its own library then either there will be two libkrb5
instances in the process (which won't share resources) or which libkrb5
instance will be used depends on the ordering of imports.C:\ProgramData\MIT\Kerberos5\krb5.ini
which contains the correct realm configuration), and then it is better to the global krb5 installation instead of installing another one.
This code was mostly copied from the python-gssapi project. The only changes were changing the name of the library and changing the formatting to make the CI happy.