Re: ctypes-python bindings

Den lör 18 juli 2026 kl 17:26 skrev Nathan Hartman <[email protected]
>:

> On Sat, Jul 18, 2026 at 10:20 AM Branko Čibej <[email protected]> wrote:
>
>> On 18. 7. 2026 16:15, Daniel Sahlberg wrote:
>>
>> Hi,
>>
>> When testing 1.15.0-rc3, I stumbled on check-ctypes-python. That
>> currently fails miserably:
>>
>> [[[
>> python: can't open file '/home/dsg/ramdisk/svn_trunk2/none': [Errno 2] No
>> such file or directory
>> sed: can't read subversion/bindings/ctypes-python/svn_all.py: No such
>> file or directory
>> cd
>> /home/dsg/ramdisk_backstorage/svn_trunk2/subversion/bindings/ctypes-python;
>> \
>>   /bin/bash "/home/dsg/ramdisk_backstorage/svn_trunk2/libtool" --tag=CC
>> --silent --mode=execute `for f in
>> /home/dsg/ramdisk_backstorage/svn_trunk2/subversion/*/*.la; do echo -dlopen
>> $f; done` python test/run_all.py
>> Traceback (most recent call last):
>>   File
>> "/home/dsg/ramdisk_backstorage/svn_trunk2/subversion/bindings/ctypes-python/test/run_all.py",
>> line 22, in <module>
>>     import setup_path
>>   File
>> "/home/dsg/ramdisk_backstorage/svn_trunk2/subversion/bindings/ctypes-python/test/setup_path.py",
>> line 31, in <module>
>>     import csvn.core
>>   File
>> "/home/dsg/ramdisk_backstorage/svn_trunk2/subversion/bindings/ctypes-python/csvn/core/__init__.py",
>> line 20, in <module>
>>     import functions
>> ModuleNotFoundError: No module named 'functions'
>> make: *** [Makefile:1050: check-ctypes-python] Error 1
>> ]]]
>>
>> I've started fixing errors one by one and I have a 444 line diff, but I'm
>> no closer to making it work.
>>
>> Given that last substantial commit was somewhere around 2011, this is
>> probably yet another feature we are not maintaining as well as we should. I
>> believe a lot of things have not been updated from Py2 to Py3 standards but
>> it seems to be other stuff as well.
>>
>>
>>
>> Ctypes-python is broken and unmaintained. Because of that, nobody uses it.
>>
>>
>> Is there any advantage having a ctypes-binding over the swig-binding?
>> Otherwise, I think we should axe this one as well - in this particular case
>> (since it currently doesn't work) - I'm on the SIGKILL squad.
>>
>>
>> Theoretically, one can build better bindings with ctypes than Swig,
>> because you get a more "native" mapping of types. But we didn't. I think 15
>> years of brokenness is long enough.
>>
>> -- Brane
>>
>>
> I'm glad there's a good bit of housecleaning going on around here. We've
> accumulated so much cruft over the years, it makes my head spin. +1 to axe
> the ctypes bindings.
>
> Cheers,
> Nathan
>
>
Thanks all! Now I did what I should have done from the start: Searching the
archives.

This was a known issue already when 1.14.0 was released, as pointed out by
Julian, James and Stefan [1]. With that in mind, I went ahead and removed
it in r1936306 and nominated for backport to 1.15.0 in r1936307.

One think I wasn't sure of is an #ifdef in subversion/include/svn_client.h:
[[[
Index: subversion/include/svn_client.h
===================================================================
--- subversion/include/svn_client.h     (revision 1936307)
+++ subversion/include/svn_client.h     (working copy)
@@ -152,7 +152,7 @@
                                apr_pool_t *pool);


-#if (defined(WIN32) && !defined(__MINGW32__)) || defined(DOXYGEN) ||
defined(CTYPESGEN) || defined(SWIG)
+#if (defined(WIN32) && !defined(__MINGW32__)) || defined(DOXYGEN) ||
defined(SWIG)
 /**
  * Create and return @a *provider, an authentication provider of type
  * #svn_auth_cred_simple_t that gets/sets information from the user's
@@ -179,7 +179,7 @@
 void
 svn_client_get_windows_simple_provider(svn_auth_provider_object_t
**provider,
                                        apr_pool_t *pool);
-#endif /* WIN32 && !__MINGW32__ || DOXYGEN || CTYPESGEN || SWIG */
+#endif /* WIN32 && !__MINGW32__ || DOXYGEN || SWIG */

 /** Create and return @a *provider, an authentication provider of type
  * #svn_auth_cred_username_t that gets/sets information from a user's
]]]
I left it alone at the moment as I wasn't sure if it would count as public
API in some way.

Cheers,
Daniel

[1] https://lists.apache.org/thread/7mdfqdobv82w7l2jtwjwcszycco3pkkl