dulwich-users team mailing list archive

[David Borowitz <dborowitz@xxxxxxxxxx>]

On Wed, Jun 23, 2010 at 08:42, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:

> Whoops, I had forgotten about this email.
>
> 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?

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.


> 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?


> Does that match what you had in mind?
>
> Cheers,
>
> Jelmer
>
>