dulwich-users team mailing list archive

[David Borowitz <dborowitz@xxxxxxxxxx>]

So, there are two steps to do here:
1. Move all the content from bin/* into various modules.
2. Replace/augment stub scripts with entry points (if we can agree on a way
to fail gracefully, etc.).

Independent of our discussion on (2) there's no reason not to start (1) now.
Jelmer, were you planning on doing that? I'd be happy to if you weren't.

On Wed, May 26, 2010 at 15:45, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:

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