[mythtv] Questions about Python bindings

[Raymond Wagner]

From: Rebecca Sutton Koeser
Sent: Tuesday, April 16, 2013 11:02 AM
> On Tue, Apr 16, 2013 at 10:07 AM, Raymond Wagner wrote:
>> Considering all the language bindings are currently tied to a specific
>> version of the database schema and backend protocol, keeping them all in 
>> the same repository makes it easier to manage compatibility and ensure
>> they get updated to match changes in the code.  For these reasons, I
>> would be reluctant to break them out into their own repositories.
>
> Hmm, I see.  Could keeping it included in the main repostiroy as a git
> submodule to accomplish the same thing (or nearly the same)?

The 'submodule' mechanism with git is really a clumsy solution to any
problem. It's not a clean, transparent solution, and is just going to
cause more problems for source users as they have to independently init and
pull all the little submodules when they clone the source. When I wrote the
TMDb v3 library last year, I ended up using 'subtree' instead, which while
still one-directional, and still requires updates in the separate repository
be pulled into the main MythTV repository, it does mean that the MythTV
repository is cloned and updated as one coherent unit.

In the case of the language bindings, right now when a developer makes a
change to the version header, the header points at a handful of other files
to make changes to at the same time. While ProgramInfo changes require
updates to MythWeb's independent repository, most changes will only require
one commit. Using submodules, a developer would have to make their change,
make their changes in each independent bindings repository, and then make
more changes to update the references to each of those independent
repositories. Subversion was nice in that you could just checkout and
maintain single a subdirectory, but git really has no similar capability. If
you're just looking to not have to keep several copies of the whole
repository around for working on different branches, take a look at the
'new-workdir' plugin, which only requires you duplicate the working copy,
and
all the repository files are symlinked back to one master.

http://code.mythtv.org/cgit/mythtv/tree/mythtv/libs/libmythbase/mythversion.
h
 
>>> and in one case where I think it is, it needs a small fix-- something
I'd
>>> like to submit as a patch but I'm hesitant to fork the entire myth repo
>>> for a one-line python change
>>
>> Then don't fork it.  You don't need to fork something just to make a
patch.
>> You don't even need a Git checkout.  Just copy the file in question, make
>> the change in the copy, and `diff` the two.
>
> Yes, sure, that's fine for a single line change.  But what about more
> substantive contributions like adding new service implementations or
> fleshing out the documentation?

It's not quite as clean and automated as a 'git diff', but you can still
just
append multiple diffs together into a single patch. In any case, any
development should be done against the master branch, which generally means
building from source, so you should already have the whole source
repository to work against anyway.

> Sounds promising.  Is the code on github anywhere?

Nope. Only local branches on my home server at the moment. Just for
reference,
the primary code repository is actually hosted on MythTV's server. Github is
serving as a public mirror to keep our server load down.