[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merging the ctypes python bindings to trunk

From: David James <james82_at_gmail.com>
Date: Mon, 22 Sep 2008 11:18:11 -0700

On Sun, Sep 21, 2008 at 3:25 PM, Arfrever Frehtes Taifersar Arahesis
<arfrever.fta_at_gmail.com> wrote:
>> I'd like to merge the ctypes python bindings to trunk using the
>> following command:
>> $ svn cp http://svn.collab.net/repos/svn/branches/ctypes-python-bindings
>> http://svn.collab.net/repos/svn/trunk/subversion/bindings/ctypes-python-bindings
>
> I would like to suggest to use `svn mv` and to place the ctypes python
> bindings in ^/trunk/subversion/bindings/ctypes-python directory. The name
> of the 'bindings' directory informs that its subdirectories contains
> Subversion bindings.

Good idea. We'll do that instead.

On Sun, Sep 21, 2008 at 11:14 PM, Sage La Torra <sagelt_at_gmail.com> wrote:
> On Sun, Sep 21, 2008 at 10:55 PM, Jeremy Whitlock <jcscoobyrs_at_gmail.com>
> wrote:
>> > Some high-level functions use deprecated Subversion functions, e.g. new
>> > depth
>> > functionality isn't used. Can ctypes python bindings be updated to use
>> > new functions?
>>
>> They can be but should they be? I think one of the features of the
>> ctypes-python-bindings is that they are forward and backward
>> compatible to Subversion 1.4.x.
>
> The general idea I think we started the higher level bindings with was that
> they made common actions easy, so I agree with this, as much as is possible.
> If users want features specific to a version, the lower level bindings are
> easily available.

Yes, I agree. I've heard from some people that they'd find it easier
to upgrade to the new bindings if they can use the new bindings with
older versions of Subversion. So, for that reason, we designed the
higher level bindings to only use functionality from Subversion 1.4.x.

It's certainly possible for us to "rev" the Python API just like we
rev the underlying C API so that people can make use of newer
features, if they want. If there is demand for this we can do it, but
I don't think it's crucial for our first release.

On Sun, Sep 21, 2008 at 5:22 PM, Eric Gillespie <epg_at_pretzelnet.org> wrote:
> "David James" <james82_at_gmail.com> writes:
>> To test on Windows, I build the csvn Python bindings on Linux and then
>> copy the generated Python files to Windows.
>
> Hmm. I wonder if this works with ctypes then? If not, what
> would I do instead?
> [...]
> try:
> providers.append(svn.core.svn_auth_get_windows_ssl_server_trust_provider())
> except AttributeError:
> pass

If the bindings are generated on Linux and copied to Windows, the
automatically generated bindings won't contain windows-specific
functions such as "svn_auth_get_windows_ssl_server_trust_provider".

Looking at the Subversion source, though, it looks like there are only
four functions that are available on some platforms but not other
platforms. We could easily make these functions available on all
platforms using a patch I've included below.

Besides the above, the API of the ctypes python bindings differs from
the SWIG Python bindings in some important ways:
  1. Pool arguments are mandatory for low-level functions
  2. We didn't divide up the low-level functions into several
submodules. All Subversion functions are in the csvn.core module.
  3. There are no "short names" for low-level functions. You need to
reference the functions by their full names (e.g.
svn_client_get_ssl_server_trust_file_provider instead of
svn.client.get_ssl_server_trust_file_provider).

Index: csvn/core/__init__.py
===================================================================
--- csvn/core/__init__.py (revision 33199)
+++ csvn/core/__init__.py (working copy)
@@ -102,3 +102,36 @@
     # Mark pool as valid
     self._is_valid = lambda: 1

+
+if sys.platform == "win32":
+
+ # Special case: Make sure that Windows-specific functions are available
+ # on Windows, even if the headers were generated on a different platform
+
+ if hasattr(_libs['svn_subr-1'], 'svn_auth_get_windows_simple_provider'):
+ svn_auth_get_windows_simple_provider =
_libs['svn_subr-1'].svn_auth_get_windows_simple_provider
+ svn_auth_get_windows_simple_provider.restype = None
+ svn_auth_get_windows_simple_provider.argtypes =
[POINTER(POINTER(svn_auth_provider_object_t)), POINTER(apr_pool_t)]
+
+ if hasattr(_libs['svn_subr-1'],
'svn_auth_get_windows_ssl_server_trust_provider'):
+ svn_auth_get_windows_ssl_server_trust_provider =
_libs['svn_subr-1'].svn_auth_get_windows_ssl_server_trust_provider
+ svn_auth_get_windows_ssl_server_trust_provider.restype = None
+ svn_auth_get_windows_ssl_server_trust_provider.argtypes =
[POINTER(POINTER(svn_auth_provider_object_t)), POINTER(apr_pool_t)]
+
+ if hasattr(_libs['svn_client-1'],
'svn_client_get_windows_simple_provider'):
+ svn_client_get_windows_simple_provider =
_libs['svn_subr-1'].svn_client_get_windows_simple_provider
+ svn_client_get_windows_simple_provider.restype = None
+ svn_client_get_windows_simple_provider.argtypes =
[POINTER(POINTER(svn_auth_provider_object_t)), POINTER(apr_pool_t)]
+
+elif sys.platform == "darwin":
+
+ # Special case: Make sure that Darwin-specific functions are available
+ # on Mac OS X, even if the headers were generated on a different platform
+
+ if hasattr(_libs['svn_subr-1'], 'svn_auth_get_keychain_simple_provider'):
+ svn_auth_get_keychain_simple_provider =
_libs['svn_subr-1'].svn_auth_get_keychain_simple_provider
+ svn_auth_get_keychain_simple_provider.restype = None
+ svn_auth_get_keychain_simple_provider.argtypes =
[POINTER(POINTER(svn_auth_provider_object_t)), POINTER(apr_pool_t)]
+
+
+

Cheers,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-22 20:18:27 CEST

This is an archived mail posted to the Subversion Dev mailing list.