Maturity/stability/longevity of ctypesgen?

[Alan Robertson]

Hi,

I've recently announced a new open source project where client libraries
will be in C (and are mostly written) and I intend to write the central
server code in python.
http://linux-ha.org/source-doc/assimilation/html/index.html

Now that I'm actually starting to write that code, I've realized how
much work it will be to do this with ctypes (I knew before I suppose,
but I'd been ignoring it). I've used SWIG before, and since I'm using
ctypes, perhaps it won't be as hard to get going as I remember...

I prototyped a little code using ctypesgen and it's not bad. I wrote
some Pythonic class wrappers for the C-classes (classes in C), and the
first simple Python class I created wasn't large and unwieldy or
unmaintainable - it was quite reasonable.

My questions come to these:
When will there be official "releases" of ctypesgen?
Is ctypesgen going to go on and become a long-term production
project/product?
How stable/usable is ctypesgen at this point?

--
Alan Robertson<al...@unix.sh>

"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce

[chris clark]

On Mon, Aug 15, 2011 at 2:30 PM, Alan Robertson <al...@unix.sh> wrote:
> Now that I'm actually starting to write that code, I've realized how much
> work it will be to do this with ctypes (I knew before I suppose, but I'd
> been ignoring it).  I've used SWIG before, and since I'm using ctypes,
> perhaps it won't be as hard to get going as I remember...
>
> I prototyped a little code using ctypesgen and it's not bad.  I wrote some
> Pythonic class wrappers for the C-classes (classes in C), and the first
> simple Python class I created wasn't large and unwieldy or unmaintainable -
> it was quite reasonable.
>
> My questions come to these:
>    When will there be official "releases" of ctypesgen?
>    Is ctypesgen going to go on and become a long-term production
> project/product?
>    How stable/usable is ctypesgen at this point?

ctypesgen is a better option for me than either manually creating the
ctypes binding or using swig. Easier for deployment and development.
Obviously I can only speak for me :-)

I guess the answers to the first 2 depend on new users and new
contributors. I only started hacking on this as a few things didn't
work for me out of the box (i.e. scratching my own itch) which is
probably the case for other people too.

RE stable/usable - I've not had any problems with stability.
Usability was pretty clear for me, things didn't work until fixed BUT
they failed noisily rather than silently so they were easy to detect.

I think SWIG may have a better solution to a single code base
supporting both 32 bit and 64 bit targets BUT I've not had to deal
with that yet (only been dealing with 32 bit). Because ctypesgen
currently pre-processes (well GCC does) the headers you end up with
binding for that platform bit-age. I think we need more people banging
on it to work out the kinks.

When ever I need to work with a dll I think in terms of ctypesgen
rather than manual ctypes or even swig. swig is very cool (and has
saved me a bunch of work), and it supports other backends, but for me
ctypesgen is the better option for Python. It would be kind of neat to
have libFFI output for more than just Python/ctypes though (e..g. Java
support).

My first SWIG project took about a day to get started with subsequent
tweaking. ctypesgen was a few hours including patching ctypesgen for
some Windows support! So I think you've made a good decision to go the
ctypes root. You still have to deal with some ctype'isms but you do
not need to rebuild the bindings unless the C code changes. With swig
I often had to change the swig bindings (which requires a rebuild)
even if the C code was the same.

Chris

[Alan Robertson]

The problem for me is very simple - if my project requires a package that doesn't come with every version of Linux (or _any_ version of Linux), then by choosing ctypesgen, I've limited the audience for _my_ code by making it harder to install.  Ideally one would just say apt-get install myproject and it would just work.  But until ctypesgen can be picked up in the same way, I've really limited _my_ project - so that that can never happen.

Until there is some kind of a semi-periodic "release" schedule with tar balls and version numbers, none of the distros is going to pick it up.  They can't really - their distribution mechanism depends on version numbering - and tar balls as well.

Part of this is a publicity problem.  It has to become fairly widely used either in the Python community such that it comes bundled with Python, or with the Linux community so that it comes with Linux.  This won't happen unless more people know about it.

Writing articles that are published in Linux Journal or one of its peers, speaking at Python and Linux conferences - these all help the project.  Other publication venues like IBM's DeveloperWorks also are good places to publish (and they are usually hungry for articles).

Someone also needs to work to get it into Debian (which feeds Ubuntu), Fedora (maybe CentOS?), and OpenSuSE.

This can't happen unless someone is committed to its success enough to do these kinds of things - or encourage others to do them.

To recap, here's what I see needs doing:

 - create releases with version numbers and tar balls
 - write articles on it in widely-read places
 - speak on it at conferences
 - work with the "free" distros to get it into Debian/Ubuntu, Fedora and OpenSuSE

This is similar to the things discussed in this article:

Top ten reasons why I won’t use your open source project

http://thechangelog.com/post/3032074343/top-ten-reasons-why-i-wont-use-your-open-source-project

They mention a README.  I agree with that one!  You might also submit your project to FreshMeat.