On 4/9/07, Sage La Torra <sagelt@gmail.com> wrote:
> It seems to me that it would be best to maintain the current bindings
> implemented in ctypes for those who are used to the current bindings.
> Since people do use the current binding (despite it's shortcomings) it
> would be nice to remain as much backwards compatibility as possible.
> From what I've seen on ctypes, it should allow the use of the same
> binding with fewer bugs, I don't see any reason not to maintain that.
It is certainly possible to reimplement the same interface as the SWIG
bindings using ctypes, but, unfortunately, I believe it would be a
monumental task to achieve complete quirk-for-quirk compatibility. I
think we should just put a note in our README file saying that the old
SWIG bindings are still available, and still work, but we encourage
users to use the ctypes bindings for new applications.
If we install the new ctypes bindings in the "csvn" folder instead of
"svn", then users can keep both the SWIG bindings and the ctypes
bindings installed at the same time.
> > Here's an example code snippet, which atomically replaces the "abc"
> > branch at "http://svn.collab.net/repos/svn/branches/abc" with a brand
> > new copy of trunk. This code snippet is useful for folks who want to
> > rebranch in a single atomic commit.
> >
> > client = Client("http://svn.collab.net/repos/svn")
> > txn = client.session().txn()
> > client.rm("branches/abc")
> > client.cp("trunk", "branches/abc")
> > txn.commit("Rebranch the abc branch from the latest revision of trunk")
(Oops. There's a typo in my code sample. I should have put txn.rm and
txn.cp here instead of client.rm and client.cp.)
David Anderson wrote:
> > 2. Write some really nice and easy to use high-level bindings in
> > Python, so that end users don't need to use the low-level C API. Write
> > detailed, friendly documentation for this new API.
>
> If ctypes lets us concentrate on delivering this, then what are we waiting for?
This is the reason why I already started using ctypes :)
David Anderson wrote:
> > - Once high-level bindings for csvn are ready, should we deprecate
> > the buggy SWIG bindings, and recommend that users pick csvn instead?
>
> Yes. I think we should find an upgrade path to push swig users towards
> the ctypes bindings asap if they are a compelling replacement, and
> have 'import svn' be ctypes bindings as of 1.6. Earlier, if we can.
>
> Should be feasible with a backcompat module that gets imported if you
> try to use old bindings functions, implements the old stuff and throws
> DeprecationWarnings. Or more simply some switch you have to flip after
> importing svn to replace the module with the ctypes module (also
> feasible afaik).
These runtime compatibility checks sound a bit tricky to implement.
Here's another proposal, which I think would be easier to implement:
1. When we first setup the new ctypes bindings, setup different
targets for building and installing them. We can build the ctypes
bindings using 'make ctypes-python' and 'make install-ctypes-python'.
The new bindings will install to a "csvn" subfolder in your Python
installation, so that you can have both the SWIG bindings and the new
ctypes bindings installed at the same time.
2. When it is time to deprecate the old SWIG bindings, we should
disable the building and installing of the SWIG Python bindings by
default, and force users to specify a configure switch to enable them.
Users who specify this configure switch might be presented with a
warning stating that the new "csvn" bindings are much better, and that
users should consider migrating to them.
David Anderson wrote:
> I would like to add a final question: Could you move the ctypes
> bindings to a branch in the main Subversion repository? It would give
> us better visibility on the progress and the evolution of the
> bindings, and lowers the barrier for participation. Besides, it'll
> have to be done if there is a consensus to replace the SWIG bindings,
> and in that case it's better to have it in our source tree early. In
> any case, I'd like it to be around so that I can attempt to find some
> non-existent hacking time to help you :-)
As soon as I have time to integrate the new ctypes bindings with the
Subversion build system, and ensure that the process for generating
ctypes code is documented and automated, I'll move csvn to a branch in
the main Subversion repository. Right now I keep the generated code in
the repository, which I know is a faux-pas :)
In the meantime we will have plenty of time to discuss my proposals on
the dev@ list, so keep the feedback coming! :)
Thanks for your support,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 10 02:27:20 2007