dulwich-users team mailing list archive

[David Borowitz <dborowitz@xxxxxxxxxx>]

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 <durin42@xxxxxxxxx> 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.
>>
>
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
>>
>>
>