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
pgpxbAVnsja1A.pgp
Description: PGP signature
