Moin,

On Friday 27 January 2006 17:42, Dominique Quatravaux wrote:
> Tels wrote:
> > However, I am _really really_ starting to wonder whether we need a
> > Kwalitee rating based on *excessive usage of prerequisites*.
>
> Doing work based on existing CPAN modules instead of reinventing the
> wheel by oneself is typically *beneficial* to quality, because it
> tremendously enhances test coverage: the prerequisites are supposedly
> useful to other things besides supporting the top-most module, and are
> tested for such alternate uses. Witness e.g. Catalyst.

Yeah, but there is a fine line between "re-inventing the wheel" and 
requiring everything-and-the-kitchen-sink just because you saved yourself 
10 lines of code. :)

And it is the latter that troubles me. I have nothing against proper 
code-reuse.

The counter-example is that there a lot of modules that are outdated, no 
longer maintained, buggy, broken, and/or in flux (read: break in the next 
version, be fixed, then break again). Depending on these modules actually 
decreases the quality of your module, because as a user you need the 
entire code base (e.g. Foo-Bar and all prereqs) to work reliable, not 
just Foo-Bar alone.

I could give countless examples for things that go "booom" and tear down 
my work with them.

> On the other hand, what about a negative kwalitee metrics of "this
> module depends on a lot of *crappy* [low-kwalitee] modules"? A case
> could be made that that denotes poor architectural oversight on the
> part of the top-most module's author.
>
> > * technically, I would have to audit each module before installing
> > it...
>
> Sorry, this is a strawman argument: human-based audits are not a
> credible defense against _intentional_ security vulnerabilities in
> code. Case in point (for C):

I didn't so much talk about security (I know this is hopeless, I am 
installing probably hundred modules a year and there is no way I could 
even remotely check them for security), but about "breakage". 

See above. I could give cases in point (like YAML breaking all my 
Makefile.PLs) but I refrain.

So, if the module you are requiring is uptodate, the author maintains it 
properly, and it isn't to alpha-beta and too complicated and/or platform 
dependend, requiring it saves lot of trouble. But there are the counter 
examples, as usual :)

Theoretically, having lots of little modules doing one thing, and doing it 
right is a good idea. In pracise, that doesn't work like that.

> http://www.brainhz.com/underhanded/
>
> Bottom line: you have to trust the CPAN authors to some extent (for
> not being evil).

Of course. But the more things you include, the mode code and the more 
authors you have to trust. Not only security wise, but also bug wise, see 
above.

> > [Lots of CPAN-related problems]
>
> Yes, CPAN can be a pain; however (kw|qu)alit(ee|y) is not meant to be
> a metrics of how easy to install a module is, but rather of whether it
> is possible to build something strong upon it, and to do so quickly
> and easily. (Or am I mistaken?)

Actually, I have no idea :) Shouldn't have dragged Kwality into it, tho.

> I have another idea. What about reversing the odds, and rewarding
> those modules that provide an all-in-one archive (e.g. CatInABox,
> http://use.perl.org/~jk2addict/journal/28071) or a pure-Perl
> zero-dependency version with perhaps a restricted feature set, in
> addition to the "full" CPAN version? (hmm, maybe this check would be
> difficult to automate)

There is the "duplicate" issue (if it contains everything it needs, you 
get duplication).

However, my idea was along the lines of a install-builder ala:

* query search.cpan.org/install-build-MY-OS-HERE/Foo-Bar/
* get back a tar.bz2/exe/tar.gz that contains every module you will need,
  including Foo::Bar and a "setup" script
* the ones you already have installed are skipped, the rest is tested,
  then installed

Basically something like CPAN, but with much less network traffic and much 
less hassle for a user. Bonus points if it gives you stuff pre-compiled 
for windows (all those ppl w/o a compiler).

Of course, *this* needs proper dependency information, and I am currently 
working on this. More on that later,

Tels

-- 
 Signed on Fri Jan 27 17:56:35 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Five exclamation marks, the sure sign of an insane mind." -- Terry
 Pratchett

Attachment: pgpxbAVnsja1A.pgp
Description: PGP signature

Reply via email to