dulwich-users team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

On Wed, 2010-06-23 at 08:55 -0700, David Borowitz wrote:
> On Wed, Jun 23, 2010 at 08:42, Jelmer Vernooij <jelmer@xxxxxxxxx>
> wrote:

>         On Fri, 2010-06-11 at 20:55 -0400, David Borowitz wrote:
>         > On Fri, Jun 11, 2010 at 20:28, Jelmer Vernooij
>         <jelmer@xxxxxxxxx>
>         > wrote:
>         >         On Fri, Jun 11, 2010 at 07:26:31PM -0400, David
>         Borowitz
>         >         wrote:
>         >         > I'm a bit torn on this issue. On the one hand, I
>         agree that
>         >         there are some
>         >         > things like excludes that we can provide
>         well-defined APIs
>         >         for rather than
>         >         > depending on specific filenames. On the other
>         hand, there
>         >         are two cases that
>         >         > I think merit keeping get_named_file around:
>         >         > 1. Allow users to read and parse files on their
>         own that
>         >         Dulwich does not
>         >         > (yet) have support for. (Presumably we would
>         encourage such
>         >         users to
>         >         > contribute their parsing code back to Dulwich
>         and/or
>         >         transition to the
>         >         > official API once one exists.)
>         >
>         >         I don't have any objections against making it
>         possible for
>         >         people to do
>         >         this but I'd rather keep it optional, not a
>         requirement for
>         >         the correct
>         >         or full functioning.
>         
>         > What do you mean by the correct or full functioning? I was
>         referring
>         > to the fact that there are a lot of miscellaneous files that
>         can
>         > already live under .git (*_HEAD, RENAMED-REF, branches/*,
>         hooks/*,
>         > logs/*). If users of dulwich want to use these files before
>         we've
>         > developed APIs for them, I think we should let them. Yes, it
>         wouldn't
>         > work for non-disk-based Repos, but at least it would work in
>         the most
>         > common case. This is just about the transitional period,
>         until we
>         > provide first-class support for those features.
>         
>         I think we agree. Summarizing: These functions should be there
>         so people
>         can get at these files while we complete the functionality in
>         Dulwich
>         but only for that reason - not as the intended way of working
>         with these
>         files. Ideally these functions should not be used at all and
>         perhaps
>         eventually be removed.

> Just to clarify, by "these functions" you mean get_named_file and
> put_named_file, correct?
Yep.

> I agree that "ideally" we'd get rid of those, but I wouldn't rule out
> the possibility that new repo files will get added to C git at a fast
> enough pace that they're always a few steps ahead of dulwich, so
> get_named_file may always be necessary.
I hope we can catch up at some point. Once we do, keeping up with the
pace with which new features in C Git are being added is doable I think.
 
>         It should be possible for implementations of the Repo
>         interface to not
>         provide these functions. If they need direct access to the
>         disk
>         representation perhaps they should bypass the Repo interface
>         altogether
>         or use an explicit wrapper on top of Repo to generate those
>         files on the
>         fly.

> I'm not sure I follow this last point. IIUC, you're talking about what
> I suggested earlier for web.py--use the (future) high-level Repo
> functions to generate any necessary files on the fly according to the
> URL requested. Right?
What I meant was having a separate class that lives on top of Repo and
can provide the required files. 

I.e. something that perhaps implements just get_named_file() and
put_named_file() but rather than by talking to disk it would call out to
methods on Repo. 

Cheers,

Jelmer

Attachment: signature.asc
Description: This is a digitally signed message part