Submodules for language bindings (was: Github?)

[Suvayu Ali]

Hi Trevor,

On Thu, May 08, 2014 at 04:35:30PM -0700, W. Trevor King wrote:
> On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:
> > On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> > > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > > > One of my TODOs is to also package the ruby bindings, and
> > > > notmuch-vim.  The only thing preventing me now is my
> > > > unfamiliarty with ruby, and Fedora packaging guidelines for
> > > > ruby-gems.
> > > 
> > > I think this is one argument argument in favor of submodules,
> > > because they make it easy to treat the bindings as separate
> > > packages.  Once you have separate packages, it's easy to delegate
> > > packaging (e.g. “I don't use the Ruby bindings, so I'm not going
> > > to maintain the Ruby-binding package.  I'll leave that to Alice,
> > > who likes Ruby, but is less familiar with $distro's Python
> > > packaging”).
> > 
> > Well as far as my understanding of rpm goes, sub-packages are
> > prefered here rather than independent packages.  I believe the
> > reason is again easier dependency tracking[1]; all sub-packages
> > share the same source rpm, so no explicit `Requires' in the spec
> > file.
> 
> It looks like sub-packages share a single spec file with the main
> package [1].  That means you'll have to have authors with the full
> range of binding-language expertise to bump that spec file (assuming
> there are any changes that require bumps).  For example, Gentoo's
> Python eclasses have gone through a few revisions in the last year or
> two, and I wouldn't expect one person to stay on top of the latest
> packaging styles for every language with notmuch bindings.  I think
> the benefit of having separate packages (and spec files, or ebuilds,
> or whatever) is that you can release notmuch-0.18 without worrying
> about all those bindings, and leave it to the other maintainers (who
> might include you) to independently package notmuch-python-0.18,
> notmuch-ruby-0.18, notmuch-go-0.18, ….  With only three sets of
> bindings, it doesn't really matter, but I think you'll want the weaker
> coupling of stand-alone packages by the time you hit a dozen
> languages.  “Bump an explicit 'Requires'” certainly seems like a lower
> barrier than “package Go bindings idiomatically for Fedora” ;).

You have a point, however I would still disagree.  You seem to use
Gentoo, and I think what you say works better for Gentoo because it is a
source distribution.  For binary distributions, this is a bit harder
(and limiting).  To explain my point with RPM specifics, if I were to
use separate spec files, python-notmuch would have:

  Requires: notmuch >= <version-string>

As you can see this only allows for tracking dependency based on
official version numbers.  With more bindings, many with different
version dependencies, this becomes quite cumbersome; more so when you
are doing snapshots (as I do for my repo[1]).  As a packager, I think I
would prefer to learn different packaging guidelines, setup my spec file
and forget about it rather than continually follow all changes.  But I
guess this is where you would argue with different responsible people, I
would not have to do all the thinking :-p.

Anyway, whichever way the devs choose to go, I (and other packagers)
will adapt.

Cheers,


Footnotes:

[1] I would love to know if anyone here uses it.  I announced it here
    when I started it, but for all I know I could be the only user!  :-p

-- 
Suvayu

Open source is the future. It sets us free.