← Back to team overview

dulwich-users team mailing list archive

Re: [RFC/PATCH] Provide an app_factory entry point for serving via Paster

 

On Sun, Mar 13, 2011 at 10:34 PM, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:
> This seems to use a logger object that's not declared anywhere, when
> e.g. the repository can't be found.

Ah, yeah. Fallout from moving the functionality to a new file. Will
fix in an updated patch.

> I had contrib/ in mind rather than dulwich/contrib, so that the paster
> app doesn't get installed, as is it is untested. The setup.py change
> also breaks compatibility with distutils.

The problem with having it in the top-level dir instead of inside
dulwich/ is that Paster won't then be able to find where the dir is.
The entry points have to point to a known location in the PYTHONPATH.
As for the distutils compatibility, I had missed the fallback import.
I can re-structure setup.py to not pass the kwarg when using
distutils; Paste.Deploy requires setuptools (again, because the
entry_points functionality).

> Alternatively, perhaps we should look at making it dulwich.paster (or
> dulwich.web.paster ? ) but also adding some unit tests, etc and keeping
> setuptools optional.

I don't particularly care where it lives, as long as it's somewhere
under dulwich/ . I can add some tests for the option parsing
functionality in the app factory; are tests required for the filter
factories? They basically just make Paster aware of their existence;
there are no options for them currently.

> Can you add a license/copyright header to paster.py ?

Will do; once I've heard back about a final home for these, I'll
submit a new patch and push to my github fork.

-- 
Thanks,

David Blewett



Follow ups

References