Re: dpkg-scanlibs
>>>>> "JB" == Jules Bean <jules@jellybean.co.uk> writes:
Me> You're the developer, of course, but I'd asking you to
Me> rethink. It doesn't have anything to do with disliking Python
Me> -- which I do -- but as a practical matter it seems kind of
Me> extraneous, for other developers and you yourself.
JB> Nah, I can't accept that argument. Wichert should use his
JB> judgement as dpkg upstream to use which language /he/ thinks
JB> is best.
Sure, of course (although I'm a little questioning of whether dpkg-dev
is really "upstream"...). I'm just trying to inform his design
decision. Or is the power of the developer so absolute that I can't
even give advice?
Here would be my points:
1) Converting the scripts is simple make-work. It doesn't add
features, only changes the implementation. (Adding features
WHILE converting, of course, is a confounding factor that's
just going to introduce more bugs.)
2) Converting the scripts is like writing them over from
scratch. You get the same kind of bugginess as from a first
implementation.
3) For good or ill, Perl and shell are the de facto scripting
languages of Debian. Throwing another language and another
interpreter into the mix -- even if it's just for
developers -- seems like it should be a very conscious
decision. If the point is to replace Perl and bash
universally, that should be stated. If the point is to have
all 3 languages be part of Debian development, that should
also be stated. Implement in haste, regret in leisure.
4) Adding another language means requiring an extra piece of
software (python) for Debian developers.
5) Adding another language means requiring a new language for
other devscript developers, bug checkers, and the like.
This isn't language advocacy -- this is basic software engineering.
If re-writing in Python is going to make things SOOOOOO much better
that it overrides these objections, so be it. If dpkg-dev is
sufficiently low priority that these things don't matter, so be it.
~ESP
--
Evan Prodromou
evan@debian.org
Reply to: