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 <[email protected]>
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).
Cheers,
Jelmer
_______________________________________________
Mailing list: https://launchpad.net/~dulwich-users
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dulwich-users
More help : https://help.launchpad.net/ListHelp
