dulwich-users team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

On Thu, 2010-05-27 at 09:34 -0700, David Borowitz wrote:
> 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.

That sounds reasonable.  I didn't have any immediate plans to work on
this, go for it. :-)

Cheers,

Jelmer

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

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