dulwich-users team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

On Wed, 2010-05-26 at 17:23 -0500, Augie Fackler wrote:
> On May 26, 2010, at 5:20 PM, Jelmer Vernooij wrote:
> 
> > On Wed, 2010-05-26 at 14:32 -0700, David Borowitz wrote:
> >> On Wed, May 26, 2010 at 13:31, Augie Fackler <durin42@xxxxxxxxx>
> >> wrote:
> >>
> >>        On May 26, 2010, at 11:48 AM, David Borowitz wrote:
> >>
> >>                I'm definitely open to the idea of simplifying and/or
> >>                combining dul-daemon
> >>                and dul-web. To be honest, it feels a little messy
> >>                every time I have to add
> >>                more code to one of those scripts. In my ideal world,
> >>                these wrapper scripts
> >>                would contain as little code as possible (basically
> >>                "if __name__ ==
> >>                '__main__': start_server('http', sys.argv[1:])").
> >>
> >>                Another possibility that moves in a slightly different
> >>                direction is to use
> >>                setuptools's entry points:
> >>                http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation
> >>
> >>                <http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation 
> >> >(Tangentially,
> >>                the reason I added the logging code to dul-web was
> >>                that I didn't want to put
> >>                the WSGI handlers in web.py, since wsgiref is not part
> >>                of the python2.4
> >>                standard library. That said, every python2.4 system I
> >>                have has wsgiref
> >>                installed, and I'm sure we could come up with a
> >>                conditional import scheme
> >>                that fails gracefully.)
> >>
> >>
> >>        I'd be a _huge_ fan of using entry points instead of
> >>        maintaining scripts - manually maintained scripts are often a
> >>        colossal pain when using something like virtualenv or
> >>        buildout.
> >>
> >>
> >> I agree, that's why I suggested it :)
> >
> >> The only downside as far as I can see is that it introduces a
> >> dependency on setuptools, but pretty much everyone has setuptools
> >> anyway (don't they?). Maybe it's possible to do something equivalent
> >> with distutils but I don't know how.
> > FWIW I didn't have setuptools installed until I received a patch for
> > Dulwich that added support for it to setup.py.
> >
> > Is there any particular benefit in using entry points rather than  
> > using
> > a trivial stub script that does "from dulwich.server import
> > start_server; start_server(sys.argv[1:])" ?
> 
> You don't have a hardcoded shebang line which users may have to edit.  
> Even #!/usr/bin/env python can be wrong (if say, the default system  
> Python is 2.6, but someone is installing against a build of 2.4 or 2.5  
> to test against a production-like environment).
Ah, ok.

As long as this doesn't mean depending on setuptools when we "import
dulwich" I don't have any objections. We could either add the trivial
stub if setuptools wasn't available or simply not install the dulwich
and dul-daemon scripts.

Cheers,

Jelmer

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