On Wed, Jun 23, 2010 at 08:42, Jelmer Vernooij <[email protected]> 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 <[email protected]> > > 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 > >
_______________________________________________ Mailing list: https://launchpad.net/~dulwich-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dulwich-users More help : https://help.launchpad.net/ListHelp
