Subject: Re: [boost] [Git] Documentation update
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-02-12 09:25:18
On Mon, Feb 11, 2013 at 11:18 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> NOTE: Part of this discussion was within the release team. But it was
> suggested that it should also be generally public. Hence I'm raising some
> of the same issues from the private discussion.
> On Mon, Feb 11, 2013 at 12:58 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Mon Feb 11 2013, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>> > On Mon, Feb 11, 2013 at 11:51 AM, Dave Abrahams <dave_at_[hidden]>
>> >> on Sun Feb 10 2013, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>> >> > On Sun, Feb 10, 2013 at 11:08 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
>> >> >
>> >> > I ask because the testing will rely on dulwich git which does not talk
>> >> > at all with bitbucket (it seems the bitbucket git server works
>> >> > differently.. not that I blame it given the disfunction that is the
>> >> > git server protocol).
>> >> Oh, that's rather lame. Is there a reason you're not going to use
>> >> libgit2 instead of dulwich?
>> > Yes.. The python bindings for libgit2 are terribly/unusably incomplete.
>> Surely they're complete enough to allow you to clone and pull, no? What
>> more do you need?
> Why would one assume that? First there is no binding to "git_clone" <
> So it's a nonstarter at step zero. Second there are no bindings for
> submodules/subrepos. Which might be an additional nonstarter if the
> git_clone didn't recurse clone/pull subrepos.
> I was faced with either implementing some of the additional
> clone/pull/checkout/update code with dulwich or likely implement even more
> for libgit2. Hence I'm sticking with dulwich. Since at least that gives the
> advantage of being pure Python.
I must be missing something. Why not just work through the python
subprocess interface? For example, here is how Marshall issues an "svn
export" in the snapshot.py script:
def svnExport(url, eol, revisionStr, dest):
command_arr = [ "svn", "export", "--non-interactive", "--native-eol",
eol, "-r", revisionStr, url, dest ]
subprocess.check_output ( command_arr )
IIRC, he does it this way because of an svn problem that was somewhat
similar to what you are facing with git - it was hard to find a python
svn binding that could be relied on in a script that had to run on
both Windows and the Mac.
As Dave points out, the git interaction is really simple, so isn't the
subprocess approach sufficient?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk