You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David James <ja...@gmail.com> on 2008/09/21 22:05:18 UTC
Merging the ctypes python bindings to trunk
Dear Subversion Developers,
At long last, the ctypes python bindings are ready to merge to trunk.
The new ctypes Python bindings offer the following advantages over the
old SWIG Python bindings:
1. First and foremost, the ctypes bindings are complete and are
generated entirely automatically. They offer complete access to all
functionality provided by the Subversion library, so there is nothing
that you won't be able to do. New features should be available in the
ctypes bindings immediately.
2. The ctypes bindings are straightforward, and don't have any
special "transformation" rules. All of the documentation for the
Subversion C library applies equally to the ctypes bindings.
3. The ctypes bindings are pure python and cross-platform. You can
generate the function definitions on one platform and copy them to
another platform without incident. In other words, your users don't
need a compiler to install the binding.
4. The ctypes bindings are both forward and backward compatible with
different versions of Subversion and different libraries, as long as
the functions you use in your programs have compatible definitions.
5. Besides the low-level bindings, the ctypes bindings have high
level classes which make it easy to access common Subversion
functionality in a Pythonic way. These classes do not offer complete
access to all Subversion features, but they are often more convenient
and easier to use than the raw ctypes library.
NOTE: The bindings have been tested on Mac OS X, Linux, and Windows.
To test on Windows, I build the csvn Python bindings on Linux and then
copy the generated Python files to Windows.
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
At first, the only way to install the ctypes python bindings will be
to follow the instructions listed in the README. After we merge to
trunk, I'd like to address the tasks listed in
http://svn.collab.net/repos/svn/branches/ctypes-python-bindings/TODO,
so that folks can install the bindings using standard make targets.
Jeremy Whitlock has volunteered to help with this process (Thanks
Jeremy!).
To help answer common questions, I've included a little FAQ document
about the ctypes python bindings below.
----------------------------------------------------------------------
Q. Will the Python SWIG bindings be deprecated?
A. This is up for discussion. I do think we should encourage folks to
move to the new ctypes bindings, especially for new systems. However,
we should also understand that many people may not want to port their
old code.
In any case, I expect that there will still be some demand for bug
fixes and features in the old bindings. In my opinion, folks who are
interested in still working on the old bindings are welcome to
continue their work. However, we should also try to update our
documentation to encourage folks to move to the new ctypes bindings.
----------------------------------------------------------------------
Q. Can I upgrade to the latest ctypes python bindings without
upgrading Subversion?
A. Yes. The current ctypes python bindings work with Subversion 1.4 or
later. The new bindings can be installed separately from Subversion
and will work with the version of Subversion you have installed.
----------------------------------------------------------------------
Q. Is it really safe to use function definitions generated on
different platforms on my machine?
A. As long as you are careful to avoid using any incompatible
functions, it is safe to use the same function definitions with
different platforms, different versions of Subversion and even with
different dependencies.
If you try to access a function which is not available on your
platform, Python will throw an exception and explain that the function
is not available. On the other hand, if the function is available but
the function definition differs across platforms in an incompatible
way, your program may crash or behave incorrectly.
----------------------------------------------------------------------
Q. APR 0.x is not binary compatible with APR 1.x. If I generate
bindings for APR 1.x, and use them with APR 0.x (or vice versa) can I
run into issues?
A. Yes. As discussed above, if you access a function which differs in
an incompatible way, you will run into issues. However, if you are
careful, and only use functions that have compatible definitions, you
can safely use the same function definitions for both versions of APR.
----------------------------------------------------------------------
Let me know if you have more questions.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by Jeremy Whitlock <jc...@gmail.com>.
> Do you need to modify any of the build files to get it to compile?
Well, right now we have a distutils installer (setup.py) that does the
build and installation for us. The idea is to update the existing
Subversion build infrastructure to expose the ability to build the
ctypes-python-bindings. We will need to create a few new make targets
to handle this but since the real work is done in setup.py, this will
be easy.
> And I think it should be possible to have both the SWIG and ctypes bindings
> installed and hopefully in use in the same process at the same time. So
> we'll need a separate module name for these besides 'svn'.
This should not be a problem either. The ctypes-python-bindings use
the 'csvn' module name instead of 'svn' and since there are no Python
extension modules for the ctypes-python-bindings, there will also be
no conflict with the existing 'libsvn'.
--
Take care,
Jeremy Whitlock
http://www.thoughtspark.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by Blair Zajac <bl...@orcaware.com>.
David James wrote:
> Dear Subversion Developers,
>
> At long last, the ctypes python bindings are ready to merge to trunk.
>
> The new ctypes Python bindings offer the following advantages over the
> old SWIG Python bindings:
> 1. First and foremost, the ctypes bindings are complete and are
> generated entirely automatically. They offer complete access to all
> functionality provided by the Subversion library, so there is nothing
> that you won't be able to do. New features should be available in the
> ctypes bindings immediately.
> 2. The ctypes bindings are straightforward, and don't have any
> special "transformation" rules. All of the documentation for the
> Subversion C library applies equally to the ctypes bindings.
> 3. The ctypes bindings are pure python and cross-platform. You can
> generate the function definitions on one platform and copy them to
> another platform without incident. In other words, your users don't
> need a compiler to install the binding.
> 4. The ctypes bindings are both forward and backward compatible with
> different versions of Subversion and different libraries, as long as
> the functions you use in your programs have compatible definitions.
> 5. Besides the low-level bindings, the ctypes bindings have high
> level classes which make it easy to access common Subversion
> functionality in a Pythonic way. These classes do not offer complete
> access to all Subversion features, but they are often more convenient
> and easier to use than the raw ctypes library.
>
> NOTE: The bindings have been tested on Mac OS X, Linux, and Windows.
> To test on Windows, I build the csvn Python bindings on Linux and then
> copy the generated Python files to Windows.
I think we should wait a full release before even beginning to deprecate the
SWIG bindings.
Do you have any performance numbers comparing the two?
> 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
Ditto Arfrever's suggestion.
Do you need to modify any of the build files to get it to compile?
And I think it should be possible to have both the SWIG and ctypes bindings
installed and hopefully in use in the same process at the same time. So we'll
need a separate module name for these besides 'svn'.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"David James" <ja...@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?
providers = [
svn.client.get_simple_provider(),
svn.client.get_username_provider(),
]
try:
providers.append(svn.core.svn_auth_get_windows_ssl_server_trust_provider())
except AttributeError:
pass
providers.extend([
svn.client.get_ssl_server_trust_file_provider(),
svn.client.get_ssl_client_cert_file_provider(),
svn.client.get_ssl_client_cert_pw_file_provider(),
])
try:
providers.append(svn.core.svn_auth_get_keychain_simple_provider())
except AttributeError:
pass
try:
providers.append(svn.core.svn_auth_get_windows_simple_provider())
except AttributeError:
pass
providers.extend([
svn.client.get_simple_prompt_provider(SimplePrompt, 2),
svn.client.get_username_prompt_provider(UsernamePrompt, 2),
svn.client.get_ssl_server_trust_prompt_provider(SSLServerTrustPrompt),
svn.client.get_ssl_client_cert_prompt_provider(SSLClientCertPrompt, 2),
svn.client.get_ssl_client_cert_pw_prompt_provider(SSLClientCertPwPrompt,
2),
])
At any rate, +1 to getting csvn in and recommending it, -1 to
desupporting swig-py (I know you weren't suggesting that, just
saying :).
Thanks.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"David James" <ja...@gmail.com> writes:
> $ python -c 'import csvn.core;
> csvn.core.svn_auth_get_windows_ssl_server_trust_provider()'
> Traceback (most recent call last):
> File "<string>", line 1, in ?
> AttributeError: 'module' object has no attribute
> 'svn_auth_get_windows_ssl_server_trust_provider'
Great! Thanks.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by David James <ja...@gmail.com>.
On Tue, Sep 30, 2008 at 1:58 PM, Eric Gillespie <ep...@pretzelnet.org> wrote:
> "David James" <ja...@gmail.com> writes:
>
>> 1. I taught ctypesgen to wrap all APIs, even if the API is not
>> present in the libraries on your platform.
>> 2. I updated the Subversion headers to include platform-specific
>> functions if 'CTYPESGEN' is defined.
>
> Can you show what this
>
> try:
> providers.append(svn.core.svn_auth_get_windows_ssl_server_trust_provider())
> except AttributeError:
> pass
>
> looks like with csvn now? It looks like you're saying that even
> these platform-specific interfaces are always bound; so how does
> an application know whether to use it or not? Does it raise
> NotImplementedError or something?
Hi Eric,
ctypesgen always attempts to bind the platform-specific interfaces at
runtime, but it only succeeds if the function actually exists on your
platform.
See the code from functions.py below:
# /home/david/dj/svn/svn-apr13/include/subversion-1/svn_auth.h: 893
for _lib in _libs.values():
if hasattr(_lib, 'svn_auth_get_windows_ssl_server_trust_provider'):
svn_auth_get_windows_ssl_server_trust_provider =
_lib.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)]
break
On Linux, the svn_auth_get_windows_ssl_server_trust_provider doesn't
exist in any library, so it isn't bound. But if you copy this header
file to a Windows machine, then the function will be bound. Here's an
example of attempting to use this function on Linux:
$ python -c 'import csvn.core;
csvn.core.svn_auth_get_windows_ssl_server_trust_provider()'
Traceback (most recent call last):
File "<string>", line 1, in ?
AttributeError: 'module' object has no attribute
'svn_auth_get_windows_ssl_server_trust_provider'
(Note also that ctypes uses the 'csvn.core' namespace, not "svn.core".)
Hope this helps,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"David James" <ja...@gmail.com> writes:
> 1. I taught ctypesgen to wrap all APIs, even if the API is not
> present in the libraries on your platform.
> 2. I updated the Subversion headers to include platform-specific
> functions if 'CTYPESGEN' is defined.
Can you show what this
try:
providers.append(svn.core.svn_auth_get_windows_ssl_server_trust_provider())
except AttributeError:
pass
looks like with csvn now? It looks like you're saying that even
these platform-specific interfaces are always bound; so how does
an application know whether to use it or not? Does it raise
NotImplementedError or something?
Thanks.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by David James <ja...@gmail.com>.
On Sun, Sep 21, 2008 at 3:25 PM, Arfrever Frehtes Taifersar Arahesis
<ar...@gmail.com> wrote:
> 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 suggestion. I've done just that in r33355 when I merged ctypesgen to trunk.
On Tue, Sep 23, 2008 at 12:13 AM, Eric Gillespie <ep...@pretzelnet.org> wrote:
> "David James" <ja...@gmail.com> writes:
>
>> 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
>
> This is OK, I guess. If more platform-specific APIs are added,
> they won't be bound until someone writing a Python app wants to
> use it :(. This is the situation with swig-py, which I hoped
> would go away. If that situation persists on a tiny subset of
> the svn API, that's still a giant improvement.
>
>> + if hasattr(_libs['svn_client-1'],
>
> I think all the svn_client forms of these are deprecated; it's
> probably better to leave them out.
Good points. To help ensure that platform-specific APIs show up
automatically, I've made two changes:
1. I taught ctypesgen to wrap all APIs, even if the API is not
present in the libraries on your platform.
2. I updated the Subversion headers to include platform-specific
functions if 'CTYPESGEN' is defined.
If people add new platform-specific functions, they should follow our
example and let ctypesgen see the functions by including the functions
in the headers if CTYPESGEN is defined. This way, it won't be
necessary to manually wrap any new APIs.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by Sage La Torra <sa...@gmail.com>.
On Sun, Sep 21, 2008 at 10:55 PM, Jeremy Whitlock <jc...@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.
Overall, I'm just excited to finally see this possibly be moved to trunk.
Re: Merging the ctypes python bindings to trunk
Posted by Jeremy Whitlock <jc...@gmail.com>.
> 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.
--
Take care,
Jeremy Whitlock
http://www.thoughtspark.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"David James" <ja...@gmail.com> writes:
> 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
This is OK, I guess. If more platform-specific APIs are added,
they won't be bound until someone writing a Python app wants to
use it :(. This is the situation with swig-py, which I hoped
would go away. If that situation persists on a tiny subset of
the svn API, that's still a giant improvement.
> + if hasattr(_libs['svn_client-1'],
I think all the svn_client forms of these are deprecated; it's
probably better to leave them out.
Thanks.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by David James <ja...@gmail.com>.
On Sun, Sep 21, 2008 at 3:25 PM, Arfrever Frehtes Taifersar Arahesis
<ar...@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 <sa...@gmail.com> wrote:
> On Sun, Sep 21, 2008 at 10:55 PM, Jeremy Whitlock <jc...@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 <ep...@pretzelnet.org> wrote:
> "David James" <ja...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merging the ctypes python bindings to trunk
Posted by Arfrever Frehtes Taifersar Arahesis <ar...@gmail.com>.
2008-09-22 00:05:18 David James napisał(a):
> Dear Subversion Developers,
>
> At long last, the ctypes python bindings are ready to merge to trunk.
>
> The new ctypes Python bindings offer the following advantages over the
> old SWIG Python bindings:
> 1. First and foremost, the ctypes bindings are complete and are
> generated entirely automatically. They offer complete access to all
> functionality provided by the Subversion library, so there is nothing
> that you won't be able to do. New features should be available in the
> ctypes bindings immediately.
> 2. The ctypes bindings are straightforward, and don't have any
> special "transformation" rules. All of the documentation for the
> Subversion C library applies equally to the ctypes bindings.
> 3. The ctypes bindings are pure python and cross-platform. You can
> generate the function definitions on one platform and copy them to
> another platform without incident. In other words, your users don't
> need a compiler to install the binding.
> 4. The ctypes bindings are both forward and backward compatible with
> different versions of Subversion and different libraries, as long as
> the functions you use in your programs have compatible definitions.
> 5. Besides the low-level bindings, the ctypes bindings have high
> level classes which make it easy to access common Subversion
> functionality in a Pythonic way. These classes do not offer complete
> access to all Subversion features, but they are often more convenient
> and easier to use than the raw ctypes library.
>
> NOTE: The bindings have been tested on Mac OS X, Linux, and Windows.
> To test on Windows, I build the csvn Python bindings on Linux and then
> copy the generated Python files to Windows.
>
> 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.
> At first, the only way to install the ctypes python bindings will be
> to follow the instructions listed in the README. After we merge to
> trunk, I'd like to address the tasks listed in
> http://svn.collab.net/repos/svn/branches/ctypes-python-bindings/TODO,
> so that folks can install the bindings using standard make targets.
> Jeremy Whitlock has volunteered to help with this process (Thanks
> Jeremy!).
>
> To help answer common questions, I've included a little FAQ document
> about the ctypes python bindings below.
>
> ----------------------------------------------------------------------
>
> Q. Will the Python SWIG bindings be deprecated?
>
> A. This is up for discussion. I do think we should encourage folks to
> move to the new ctypes bindings, especially for new systems. However,
> we should also understand that many people may not want to port their
> old code.
>
> In any case, I expect that there will still be some demand for bug
> fixes and features in the old bindings. In my opinion, folks who are
> interested in still working on the old bindings are welcome to
> continue their work. However, we should also try to update our
> documentation to encourage folks to move to the new ctypes bindings.
>
> ----------------------------------------------------------------------
>
> Q. Can I upgrade to the latest ctypes python bindings without
> upgrading Subversion?
>
> A. Yes. The current ctypes python bindings work with Subversion 1.4 or
> later. The new bindings can be installed separately from Subversion
> and will work with the version of Subversion you have installed.
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?
--
Arfrever Frehtes Taifersar Arahesis