My arguments below notwithstanding, I think very thin stub scripts would be better than what we have now, so I'm glad we're discussing it :)
On Wed, May 26, 2010 at 15:23, Augie Fackler <[email protected]> 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 <[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. >> > I guess what I really meant by that was either they have it, or it's just an apt-get install (or equivalent) away. > 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). > This arises for me at work whenever I have to test something on 2.4. My OS only comes with 2.6 in /usr/bin but all our production tools depend on 2.4, which lives somewhere completely different. I understand it enough to work around it, but it still bites me occasionally. I think there's also a minor advantage to having all the stub scripts as one line in one file, rather than having a whole directory of individual scripts to maintain. But this concern alone is probably not enough to outweigh the concerns about adding dependencies. >> 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
