Re: [boost] [Git] Documentation update

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]>
>> wrote:
>> >
>> >>
>> >> 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" <
> https://github.com/search?q=git_clone+repo%3Alibgit2%2Fpygit2&type=Repositories&ref=advsearch&l=>.
> 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:

import subprocess
...

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?

--Beman