Re: [Vxl-users] [Vxl-maintainers] Python bindings for VXL and NumPy integration

[Matt L. <mat...@ki...>]

Brendan,

I would also be in favor of splitting contrib off into a separate
repository, or even one repository per contributor.  This would make
release management much easier.  The official release would only contain
VXL core libraries.  Each contributor would then have the responsibility
of making releases of their own contrib sections, if they care about
releases.  The Python bindings could be another add-on repository.

At Kitware we would handle this setup with what we call "superbuilds".
A superbuild is a repository that refers to specific commits of various
other repositories.  So you could checkout and build the various
projects separately if you want, but you can also checkout the
superbuild and it will checkout all the repositories you need and build
everything in one massive build.  This allows for smaller sub-projects
that are easier to manage, but also makes it easy to do a single unified
build of everything if that is what you want.

I'm not sure if this can be done effectively with subversion, but it
works well with git using the git submodule feature.  At Kitware we have
migrated all of our code repositories from svn and cvs to git.  In fact
we do all our VXL work in git and push changes back upstream via the
git-svn interface.  Git has a bit of a learning curve, but is so much
more powerful than svn or cvs that once you learn it is very hard to go
back.

What is the VXL community's feeling on moving to git?  If a good portion
of developers are already familiar with git then it maybe it would make
sense to switch.  I can see the possibility of Kitware migrating VXL to
git, splitting it into separate repositories, setting up the superbuild,
and then taking responsibility for making the stable releases of VXL
core.  I can't promise anything right now because I have to check that
we can find funding to do this.  However, we certainly have the
technical experience to do this migration if the community is in favor
of it.

Moving from svn to git is about more than the submodule feature.  It's a
fundamental shift from centralized version control to distributed
version control.  It requires a totally different mindset on version
control.  I expect there will need to be a lot of debate about whether
or not to migrate to git and also what the work flow would be if we
adopted git.  git supports various different development work flows, the
simplest of which is the linear, single-branch of history used by cvs
and svn.  There are other work flows that are better suited toward
managing stable releases. 

--Matt

On Mon, 2012-02-13 at 20:26 +1300, Brendan McCane wrote:
> Hi Matt,
> 
> I am very much in support of this move. I can see benefits and
> draw-backs to both option 1 and 2 below. I have a slight preference for
> option 2, but in that case, I would prefer all of contrib to be split
> off into a separate project. This has the advantage of making official
> releases rather easier since core does not change often (but that's my
> bias showing both as the release guy and someone who has used very
> little of contrib).
> 
> Either way, I'm strongly in favour of python bindings for vxl. I might
> be able to help a bit, but probably shouldn't be relied upon for any
> heavy lifting.
> 
> On Thu, 2012-02-09 at 15:26 -0500, Matt Leotta wrote:
> > VXL users and maintainers,
> > 
> > At Kitware we've toying with the idea of creating Python bindings for
> > VXL.  The main goal would be to allow the use of VXL's core classes and
> > functions from Python.  We also want to integrate vnl and vil tightly
> > with NumPy.  OpenCV and many other C++ libraries have similar
> > functionality.  We've done some proof of concept test and found that,
> > for example, we can wrap a vil_image_view as a NumPy array and
> > manipulate the underlying memory without deep copying.  The reverse is
> > also possible.
> > 
> > Before we invest much more effort into this I'd like to gauge developers
> > interest and acceptance of this idea.  I suspect the interest from VXL
> > users would be high, but I'm less confident such bindings could actually
> > be committed back to the VXL repository without updating our policies.
> > We would be using Boost.Python to create the bindings since this is far
> > easier than manually doing it with Python's C interface.  In addition to
> > Boost this would require linking to Python and NumPy libraries.  I would
> > not want to have to put any of these in v3p.  The code for these binding
> > would also make heavy use of modern C++ features, like namespaces, that
> > are generally frowned upon in VXL.
> > 
> > I see this as an optional component to VXL, so either:
> > 
> > 1) This code is contributed to the VXL repository, but lives in a
> > separate subdirectory, and is disabled in CMake by default.  Building
> > Python bindings would require the user to provide Python, Boost.Python,
> > and NumPy.
> > 
> > 2) The code is a separate project that depends on VXL and has its own
> > version control repository.  It would probably use a newer version of
> > CMake, use "newer" C++ features (C++03, not C++11), and be maintained
> > separately.
> > 
> > Either way, we would probably set up the framework and wrap just some
> > key classes and functions at first.  Initial focus would be on vil and
> > vnl, secondary focus on vgl and vpgl.  We would probably not go much
> > beyond that and allow the community to contribute additional bindings as
> > needed.  There is no need to wrap some libraries like vpl and vul since
> > Python already has these capabilities.
> > 
> > Does anyone have any opinions on this matter?  Is anyone interested in
> > helping if we can get the ball rolling?
> > 
> > Thanks,
> > Matt
> > 
> > 
> > ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing 
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > Vxl-maintainers mailing list
> > Vxl...@li...
> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
> 
>