dulwich-users team mailing list archive
-
dulwich-users team
-
Mailing list archive
-
Message #00482
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