Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Moin, On Thursday 26 January 2006 15:26, Thomas Klausner wrote: Hi! I finally found some tuits to work on CPANTS again. As the previous implementation had some drawbacks, I started from scratch, and from another direction. I just uploaded Module::CPANTS::Analyse to CPAN. MCA contains most of the previous Kwalitee indicators and some code to check if one distribution tarball conforms to those indicators. It also includes a script calls icpants_lint.pl/p which is basically a frontend to the module. Very cool. However, I am _really really_ starting to wonder whether we need a Kwalitee rating based on *excessive usage of prerequisites*. On the box I tried to use it I had to install basically dozens of modules, with a few twists: * cant use CPAN (due to network security), so have to download everything manually, transfer it via USB stick etc. * technically, I would have to audit each module before installing it... * perl Makefile.PL make test make install is the mantra for everything except: ** some modules use Module::Build and the above doesn't work ** for some modules Makefile.PL will succeed, even tho the PREREQ are not met, meaning you get lots of silly test failures (at least it doesn't install the module because make test will fail) * in the middle of the operation search.cpan.org broke down, so I had to stop and wait 15 mins until I could continue (Murphy :) * in the end, tests fail, so all was probably for naught: Failed Test Stat Wstat Total Fail Failed List of Failed -- t/analyse.t2 512102 20.00% 6-7 Failed 1/10 test scripts, 90.00% okay. 2/56 subtests failed, 96.43% okay. make: *** [test] Error 255 :-( Will send you the full output off-list. I am still considering building something[0] that shows the module-dependency as a graph to show how bad the problem has become. Even simple modules like YAML seem to include everything and the kitchen-sink :-( Best wishes, Tels [0] As soon as I can extract the nec. data from CPANTS, which has failed the last two times I tried that for very similiar reasons - lots of dependencies, test failures, database scheme changed etc. ... -- Signed on Fri Jan 27 15:33:57 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. The need for a Steam account to play HL2 is like having to login to MS Passport to play Minesweeper. -- Tels pgpCaSLGyRq85.pgp Description: PGP signature
Conversion oneliner t-shirt
Because of the favourable response to the prototype I wore during the post-euroscon Amsterdam.pm meeting, and because Cafepress finally has black shirts, it is now available for everyone who wants one. http://www.cafepress.com/perl6 Please note that although I'm spamming this, there's no profit in there for me, or anyone except Cafepress. (I did add $ 0.01 because I think .99 values are incredibly silly.) Please donate to TPF separately :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Test Script Best-Practices
James E Keenan [EMAIL PROTECTED] writes: Tyler MacDonald wrote: The convention in running tests is to use the 'prove' command; prove t/01_class.t That should take care of blib for you. Not quite. You need to call the -b option to get prove to read from blib. When I've been revising one of my already installed modules I've gotten burned by failing to explicitly call: prove -b t/01_class.t Quite often -l (to read from lib/) is enough, depending on your module build complexity. For -b you have to call ./Build before prove, which can be annoying and/or difficult to remember. Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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): http://www.brainhz.com/underhanded/ Bottom line: you have to trust the CPAN authors to some extent (for not being evil). * perl Makefile.PL make test make install is the mantra for everything ... including a credible surrogate for auditing code whose author you do trust. Actually that's the best the industry can do yet, short of sandboxing (which is orthogonal to the issue at hand) and program proving (which is a pipe dream for Perl, needless to say) ** some modules use Module::Build and the above doesn't work Not all Module::Build modules lack a working Makefile.PL. My idea of measuring the average kwalitee of the dependencies would of course capture this (depends on a module that is not buildable by CPAN = bad, baad) [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?) 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) - -- Dominique QUATRAVAUX Ingénieur senior 01 44 42 00 08 IDEALX -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD2k2AMJAKAU3mjcsRAixAAKCECzfjIpHY4ACZcRVku5ykLGuR2wCgooHO vzWpvzCv+w6jmTWZ4ry68ms= =L8V7 -END PGP SIGNATURE-
Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
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 pgpDhIMRGw8pC.pgp Description: PGP signature
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Moin, On Friday 27 January 2006 18:48, Chris Dolan wrote: On Jan 27, 2006, at 11:23 AM, Tels wrote: 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). I think you just described ActiveState's Perl Package Manager (PPM). http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ I lived under the expression that it is: * for windows only * only includes Foo-Bar, but not it's dependecies Best wishes, Tels -- Signed on Fri Jan 27 19:00:59 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Duke Nukem Forever will come out before Doom 3. - George Broussard, 2002 (http://tinyurl.com/6m8nh) pgpy1BtF17YN1.pgp Description: PGP signature
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 12:01 PM, Tels wrote: On Friday 27 January 2006 18:48, Chris Dolan wrote: On Jan 27, 2006, at 11:23 AM, Tels wrote: 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). I think you just described ActiveState's Perl Package Manager (PPM). http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ I lived under the expression that it is: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 11:23 AM, Tels wrote: 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). I think you just described ActiveState's Perl Package Manager (PPM). http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
testers.cpan.org out of sync with search.cpan.org?
On several of my modules, the search.cpan.org page shows test passes/failures, whereas when I follow the link to see the actual list, there are no tests reported. eg: http://search.cpan.org/~CRAKRJACK/Class-Driver-0.004/ Usually this clears up in about a day, but in some cases it's been 3 or 4 days now and search.cpan.org is telling me that tests have run, but testers.cpan.org doesn't seem to know anything about them. Is this a common problem? Is it fixable? Is there somewhere else I can go to find out about the results of my modules being tested, short of subscribing to the mailing list where *every* module tested gets posted? Thanks, Tyler
Graph::Dependency 0.01
Moin, the aforementioned module has entered the CPAN. I put up a few examples here: http://bloodgate.com/perl/graph/dependency/examples/ It is: * a hack, using wget, Module::CoreList, Graph::Easy and graphviz. * failing for modules that do not have a META:yml file yet If you want to see a dependency graph for $YOUR_FAVOURITE_MODULE, just drop me a note and I add it. Hope this is interesting to someone, Tels -- Signed on Fri Jan 27 19:47:52 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Call me Justin, Justin Case. pgpfEcPmSIY8f.pgp Description: PGP signature
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Jan 27, 2006, at 12:30 PM, Tyler MacDonald wrote: Chris Dolan [EMAIL PROTECTED] wrote: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Um, no it isn't! http://ppm.activestate.com/ PPMs are built for a variety of platforms, windows, OSX, and various unixes. You can download ActivePerl for these platforms here: http://www.activestate.com/Products/Download/Download.plex? id=ActivePerl - Tyler Sweet! I didn't know that. Yay ActiveState! Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Chris Dolan [EMAIL PROTECTED] wrote: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Um, no it isn't! http://ppm.activestate.com/ PPMs are built for a variety of platforms, windows, OSX, and various unixes. You can download ActivePerl for these platforms here: http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl - Tyler
Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Fri, Jan 27, 2006 at 03:42:58PM +0100, Tels wrote: I am still considering building something[0] that shows the module-dependency as a graph to show how bad the problem has become. [0] As soon as I can extract the nec. data from CPANTS, which has failed the last two times I tried that for very similiar reasons - lots of dependencies, test failures, database scheme changed etc. ... A member of Birmingham.pm has already written it, although his server seems to be down at the moment. Considering it is quite a nice little tool, I'll see if he'll let me host it on the Birmingham.pm server for you all to have a play with. Barbie.
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Fri, Jan 27, 2006 at 10:30:47AM -0800, Tyler MacDonald wrote: Chris Dolan [EMAIL PROTECTED] wrote: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Um, no it isn't! http://ppm.activestate.com/ PPMs are built for a variety of platforms, windows, OSX, and various unixes. You can download ActivePerl for these platforms here: http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl - Tyler I'm somewhat new to the Perl community, so I don't know much history about PPM + perl, but I think PPM is actually a pretty good tool. We use it extensively for the applications we develop. All of our product code is built into perl modules, and then we build them into ppd/tarballs. Then installing the product is just a matter of installing an ActivePerl (which gives us ppm), and then ppm installing all the packages. This makes it really easy to deploy and re-use code. I'm really interested in how other people who build products in code build/deploy their stuff. I think this would be rad: - PPM becomes part of the perl core - All CPAN packages are built to into PPDs automatically on common platforms - PPM is extended to allow installing into non-root locations This would allow non-perl people to install perl packages much easier, without having to mess with the CPAN shell and running tests. It would also make installing CPAN packages into hosted environments much easier. Any thoughts? Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone.
Interesting Paper on Prototype Based OO w/ Multi-Methods
Hello All, Recently on #perl6 putter found the Slate language (http://slate.tunes.org/) in our search for some information about Smalltalk. Slate is a prototype based OO language which uses multi method dispatch instead of more traditional method dispatch. As I flipped through some of the papers on the site, I couldn't help thinking back to some of the more recent musing of Larry on the Perl 6 object model. The paper which is most complete is this one: http://tunes.org/~eihrul/ecoop.pdf Or for those with shorter attention spans, there are some slides which give a high level overview of what is in the paper. That can be found here: http://tunes.org/~eihrul/talk.pdf I think there is definitely some valuable information to be found in here, which we can use in the further development of the Perl 6 obejct model. Stevan
Re: Conversion oneliner t-shirt
On 1/27/06, Juerd [EMAIL PROTECTED] wrote: Because of the favourable response to the prototype I wore during the post-euroscon Amsterdam.pm meeting, and because Cafepress finally has black shirts, it is now available for everyone who wants one. http://www.cafepress.com/perl6 After some discussion with Juerd on #perl6, I'll also print some (in black preferably, or in other darker colours) and bring with me to OSDC.il and GPW as giveaway presents. :-) Audrey
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Moin, On Friday 27 January 2006 22:26, Luke Closs wrote: On Fri, Jan 27, 2006 at 10:30:47AM -0800, Tyler MacDonald wrote: Chris Dolan [EMAIL PROTECTED] wrote: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Um, no it isn't! http://ppm.activestate.com/ PPMs are built for a variety of platforms, windows, OSX, and various unixes. You can download ActivePerl for these platforms here: http://www.activestate.com/Products/Download/Download.plex?id=Active Perl I'm somewhat new to the Perl community, so I don't know much history about PPM + perl, but I think PPM is actually a pretty good tool. Except that it seems to not be able to build most stuff on the two most common platforms. Looky here: http://ppm.activestate.com/BuildStatus/5.8-G.html GD cant be build. Graph::Easy can't be build on quite a few things because Scalar-List-Util can't be build, etc. etc. In fact, the entire page under G looks scary with so much red. Graph::Easy and GD work just fine when compiled with CPAN/manually under Linux, but aren't available via PPM. That basically makes it useless for me :) Best wishes, Tels -- Signed on Fri Jan 27 22:33:10 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. It is true that some lawyers are dishonest, arrogant, greedy, venal, amoral, ruthless buckets of slime. On the other hand, it is unfair to judge the entire profession by a few hundred-thousand bad apples. -- The Washington Post pgpUvUpjClys6.pgp Description: PGP signature
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Fri, Jan 27, 2006 at 10:37:01PM +0100, Tels wrote: Moin, On Friday 27 January 2006 22:26, Luke Closs wrote: On Fri, Jan 27, 2006 at 10:30:47AM -0800, Tyler MacDonald wrote: Chris Dolan [EMAIL PROTECTED] wrote: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? Um, no it isn't! http://ppm.activestate.com/ PPMs are built for a variety of platforms, windows, OSX, and various unixes. You can download ActivePerl for these platforms here: http://www.activestate.com/Products/Download/Download.plex?id=Active Perl I'm somewhat new to the Perl community, so I don't know much history about PPM + perl, but I think PPM is actually a pretty good tool. Except that it seems to not be able to build most stuff on the two most common platforms. Looky here: http://ppm.activestate.com/BuildStatus/5.8-G.html GD cant be build. Graph::Easy can't be build on quite a few things because Scalar-List-Util can't be build, etc. etc. In fact, the entire page under G looks scary with so much red. Graph::Easy and GD work just fine when compiled with CPAN/manually under Linux, but aren't available via PPM. That basically makes it useless for me :) These are issues with ActiveState's PPM building process, not the idea of using PPM for package distribution, no? Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone.
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Randy Kobes distributes Win32 PPMs for some of the modules that ActiveState doesn't provide. It is not entirely automated, so the latest code isn't always available. But Randy is very helpful if there's anything you want to see. http://theoryx5.uwinnipeg.ca/ppms/ -Jeff I'm somewhat new to the Perl community, so I don't know much history about PPM + perl, but I think PPM is actually a pretty good tool. Except that it seems to not be able to build most stuff on the two most common platforms. Looky here: http://ppm.activestate.com/BuildStatus/5.8-G.html GD cant be build. Graph::Easy can't be build on quite a few things because Scalar-List-Util can't be build, etc. etc. In fact, the entire page under G looks scary with so much red. Graph::Easy and GD work just fine when compiled with CPAN/manually under Linux, but aren't available via PPM. That basically makes it useless for me :) Best wishes, Tels -- Signed on Fri Jan 27 22:33:10 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. It is true that some lawyers are dishonest, arrogant, greedy, venal, amoral, ruthless buckets of slime. On the other hand, it is unfair to judge the entire profession by a few hundred-thousand bad apples. -- The Washington Post __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Friday 27 January 2006 14:43, Tyler MacDonald wrote: Part of the problem is that a lot of modules out there are fully functional even when a few of their tests fail due to assumptions about the environment they are being tested in. Another part is that the ActiveState perl package build process (cpanrun) doesn't behave exactly the same way as CPAN::YACSmoke. So, a lot of packages that build successfully for CPAN testers don't for ppm.activestate.com (and sometimes, the opposite is true). Indeed, another of the longstanding issues with the AS repository is that AS rarely reports build and test errors back to module authors. (For errors where their build system as at fault, I don't mind.) Yet Luke's idea of promoting PPM (or a similar system) as a binary installation process has a lot of merit. I hesitate to want to support users who've installed any of my software without running the tests themselves, but a system that could install modules as easily as through the CPAN or CPANPLUS shell without requiring compilation could be very useful. -- c
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Jeffrey Thalhammer [EMAIL PROTECTED] wrote: Randy Kobes distributes Win32 PPMs for some of the modules that ActiveState doesn't provide. It is not entirely automated, so the latest code isn't always available. But Randy is very helpful if there's anything you want to see. http://theoryx5.uwinnipeg.ca/ppms/ What is actually happening on ppm.activestate.com, is that only modules that pass all their unit tests are packaged for the general public. IMHO this is a great idea, since then people who are ppm installing stuff from activestate repoes can be reasonably(*) confident that the package will work on their system. Part of the problem is that a lot of modules out there are fully functional even when a few of their tests fail due to assumptions about the environment they are being tested in. Another part is that the ActiveState perl package build process (cpanrun) doesn't behave exactly the same way as CPAN::YACSmoke. So, a lot of packages that build successfully for CPAN testers don't for ppm.activestate.com (and sometimes, the opposite is true). Gozer (the new ActiveState CPAN-PPM guru) is working hard to get as many of these failing modules working properly ASAP. In the past few weeks he's implemented the PERL_MM_USE_DEFAULT and AUTOMATED_TESTING environment variables in cpanrun. He's also working on getting as many non-perl dependancies as possible (eg; libgd, libpg, etc) installed on his build boxes so that XS-based packages that depend on these things can be built. A lot of packages still dont get released through activeperl, but the situation is getting better. There's still always going to be packages that fail unit tests, that people want anyways; I think keeping those packages out of a quality assured repo is a neccessary sacrifice to maintain integrity. Maybe it would be a good idea for there to be an official unstable PPM repo where packages that built, but failed unit tests, get placed -- then somebody who wants to be on the bleeding edge can add that repo to their list to get at the packages, and maybe even lend a hand in figuring out why the tests are failing. Cheers, Tyler
Re: Dependency trees and ppm
Moin, On Friday 27 January 2006 23:43, Tyler MacDonald wrote: Jeffrey Thalhammer [EMAIL PROTECTED] wrote: Randy Kobes distributes Win32 PPMs for some of the modules that ActiveState doesn't provide. It is not entirely automated, so the latest code isn't always available. But Randy is very helpful if there's anything you want to see. http://theoryx5.uwinnipeg.ca/ppms/ What is actually happening on ppm.activestate.com, is that only modules that pass all their unit tests are packaged for the general public. IMHO this is a great idea, since then people who are ppm installing stuff from activestate repoes can be reasonably(*) confident that the package will work on their system. [snip a bit] Yes, but most modules shouldn't (or don't) fail tests. And yet Math::Big for instance can't be build by ActiveState for linux :-/ It would be good if first pure-perl modules that don't require much to work (like Math::BigInt::foo) could be made to work :) See here: http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/Math-BigInt-Constant-1.06.txt That shouldn't happen. Best wishes, Tels -- Signed on Fri Jan 27 23:57:04 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. This email violates U.S. patent #6,756,999 http://tinyurl.com/2vuqm: [ [ Konsoles* ] [ Mozilla ] [ KMail ]] pgpNHq8tYctW4.pgp Description: PGP signature
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Moin, On Friday 27 January 2006 23:55, chromatic wrote: On Friday 27 January 2006 14:43, Tyler MacDonald wrote: Part of the problem is that a lot of modules out there are fully functional even when a few of their tests fail due to assumptions about the environment they are being tested in. Another part is that the ActiveState perl package build process (cpanrun) doesn't behave exactly the same way as CPAN::YACSmoke. So, a lot of packages that build successfully for CPAN testers don't for ppm.activestate.com (and sometimes, the opposite is true). Indeed, another of the longstanding issues with the AS repository is that AS rarely reports build and test errors back to module authors. (For errors where their build system as at fault, I don't mind.) Yet Luke's idea of promoting PPM (or a similar system) as a binary installation process has a lot of merit. I hesitate to want to support users who've installed any of my software without running the tests themselves, but a system that could install modules as easily as through the CPAN or CPANPLUS shell without requiring compilation could be very useful. Which is probably _very_ exactly what the FreeBSD port system is doing. And from what little I see from them (I google sometimes for my own modules) they are very uptodate and make my modules in the latest version available. (Heh, thanx FreeBSD porters!) ActiveState rarely builds anything of my stuff due to whatever reasons - and most of them looked like their own build system stumbling over it's own legs :-/ Best wishes, Tels -- Signed on Sat Jan 28 00:04:32 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Eat, eat, eat, eat the delicious sandwich! -- Elan the Bard (Order of the Stick) pgpw6YJvI0MXM.pgp Description: PGP signature
Re: Dependency trees
On Fri, Jan 27, 2006 at 11:56:11PM +0100, Tels wrote: Given that ppm seems YetAnotherPerlPackager and that even ActiveState can't get it to build most of the CPAN packages, I am not convinced that using ppm over CPAN/Module::Build is a good or even working idea. PPM is much simpler for end users than CPAN/CPANPLUS/Module::Build. The CPAN shell is simply too complex for most non-perl people to easily install perl packages. You shouldn't need to be a perl hacker to install perl modules or (especially) applications. Yes, you can build your own packages with it and distribute them, but that doesn't help you to install Foo-Bar and all it's dependencies from CPAN... ??? `ppm install Foo-Bar` would install Foo-Bar and all dependencies (assuming they were present on ppm's repositories). I should also mention that while I have an ActiveState email address, I actually work for Sophos, so I'm just a consumer of their stuff. I completely agree with your concerns that the AS ppm repo doesn't contain all packages - this needs to be fixed if PPM is to be used on a larger scale. My point is just that what makes PPM so good is that it doesn't futz about with compiling code and running tests. It just installs the code and goes home. Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone.
What am I doing wrong? (Perl, UTF-8 and cyrillic)
Hello, I was doing some I18N of a bunch of existing CGI scripts and encountered a problem. I guess I'm making some very basic error, but I'm stuck with this for a day and I thought I may ask. I have my strings in UTF-8. I read most of them from file, do some processing and spit them out of the CGI-script. Let say I do this: $x=~y/a-ya/A-YA/; Here, with a I mean cyrillic a (1'st letter of the cyrillic alphabet), with ya - ciryllic ya (last letter of the cyrillic alphabet). I don't want to post ciryllic chars here - I don't know how they will show, but you understand what I mean. This doesn't work properly. I suppose it should convert the characters to uppercase, but what happens is that some characters do not get converted to uppercase, while other get converted to wrong characters. Another thing is that when I say substr($cyrillicString,5,1), the character returned is always invalid (shows as a white question on a black diamond). All other cyrillic strings, that are not manipulated show properly. The problem happens when I try to get a character from a string, to split it, things like this. What am I doing wrong? If you reply RTFM, I'll understand and will not complain... :-) - Alex
Re: Test Script Best-Practices
Steffen Schwigon wrote: Quite often -l (to read from lib/) is enough, depending on your module build complexity. For -b you have to call ./Build before prove, which can be annoying and/or difficult to remember. I'll have to try that out. My modules all use MakeMaker rather than Module::Build. And I'm generally using 'prove' to trouble-shoot individual tests after I've already run 'make test' and identified which test files have failures. jimk
Binary distributions
Why do we need to reinvent this wheel ? Most of the platforms out there have some binary packaging system. Solaris has their own, Linuxen have rpm/deb or whatever else they have. ActiveState with its binary Perl distributions have ppm and while that's not perfect we read that they are working on fixing the issues. As someone just mentioned the FreeBSD ports are kept very up-to-date. I have just moved to Ubuntu and thought I will try to rely on apt-get to install my Perl modules. Quckly I hit a wall and could not install some of the basic modules. I did not have the time to investigate and check if I made a mistake or if there is a .deb repository with the latest CPAN modules for Ubuntu. I reverted to use CPAN.pm. BTW here is an article on how to build Debian packages of Perl modules: http://www.debian-administration.org/articles/78 Anyway I think instead of trying to setup our own binary distribution we might want to make sure there are up to date repositories of Perl modules for the major distributions (and I am not talking only about Linux distributions here). It can be done by helping the people who already maintain some of these distributions or by setting up repositories such as debian.cpan.org, fedora.cpan.org, etc... Gabor
Can Parrot and Perl6 run on z/OS UNIX?
Hi The Parrot documet says that Parrot compiles and runs on a large number of platforms, including all common ones. The Parrot team is committed to supporting the following combinations as core platforms: Linux (x86), Cygwin, Win32, Tru64, OpenVMS (Alpha), Solaris (Sparc), FreeBSD (x86). a)Can Parrot and Perl6 run on z/OS UNIX as well? If so what is the support currently available? b)Are the features currently available will also be present for z/OS UNIX? c)Are there any architecture dependency issues? Thanks in advance regards Ravi Sastry
Re: Binary distributions
Gabor Szabo [EMAIL PROTECTED] wrote: I have just moved to Ubuntu and thought I will try to rely on apt-get to install my Perl modules. Quckly I hit a wall and could not install some of the basic modules. I did not have the time to investigate and check if I made a mistake or if there is a .deb repository with the latest CPAN modules for Ubuntu. I reverted to use CPAN.pm. BTW here is an article on how to build Debian packages of Perl modules: http://www.debian-administration.org/articles/78 Anyway I think instead of trying to setup our own binary distribution we might want to make sure there are up to date repositories of Perl modules for the major distributions (and I am not talking only about Linux distributions here). It can be done by helping the people who already maintain some of these distributions or by setting up repositories such as debian.cpan.org, fedora.cpan.org, etc... That is such an incredibly good idea. I've got plenty of bandwidth to burn and I'm willing to set up debian.cpan.org. I think the most obvious way to automate this would be to take advantage of the whole perl package / dependancy / build / test process that the YACsmoke module already offers us. Maybe CPAN::YACSmoke::Plugin::Packager, with children ::Deb, ::RPM, ::PPM, etc. These modules could just stick their built packages into an outgoing directory (or maybe multiple, noarch, i386, etc); some distros would be able to just nab those and their metainfo and roll a repo out of it, maybe some we'll have to write tools to do that for as well. - Tyler
Kwalitee in your dependencies (was CPAN Upload: etc etc)
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?) I disagree. A lot of the kwalitee metrics support best practices. Things that aren't entirely necesary to core function but are the mark of a good module. Hence the does anyone else use this module point. If someone else is using your module, it must be $good. Likewise, if your module installs all the way from a vanilla installation and all it dependencies go on cleanly, then I think that's well and truly worthy of a point. Something like a clean_install metric. If there are any FAIL entries in CPAN Testers against the current version of your module, you lose a point. If there are any FAIL entries against the current version of any of your dependencies, you fail to (or rather, if you dependency doesn't have the point, you can't either) By the way, if someone wants to implement this I'd recommend interative modification rather than Algorithm::Dependency-style order discovery. Just go down the list checking dependencies and removing the point checking deps. Count the number of point removes for each interaction until it reaches zero. Personally I think this would be great. The PITA-based (what I'm thinking of calling) Vanilla Testers system is intended for a similar purpose. Test modules based on installation from scratch. With this focus on more-practical aspects, we can zero on the module within CPAN that are causing the most problem FAR more easily, and we know where attention needs to be placed. Adam K 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) - -- Dominique QUATRAVAUX Ingénieur senior 01 44 42 00 08 IDEALX -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD2k2AMJAKAU3mjcsRAixAAKCECzfjIpHY4ACZcRVku5ykLGuR2wCgooHO vzWpvzCv+w6jmTWZ4ry68ms= =L8V7 -END PGP SIGNATURE-
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
Chris Dolan wrote: On Jan 27, 2006, at 12:01 PM, Tels wrote: On Friday 27 January 2006 18:48, Chris Dolan wrote: On Jan 27, 2006, at 11:23 AM, Tels wrote: 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). I think you just described ActiveState's Perl Package Manager (PPM). http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ I lived under the expression that it is: * for windows only * only includes Foo-Bar, but not it's dependecies It will auto-install dependencies just like CPAN, I believe. And, yes, it's currently Windows-only. Didn't you offer bonus points for Windows?? No it isn't. ActivePerl runs on 8 platforms, and the ppms are available for said 8 platforms. Adam K
Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)
On Friday 27 January 2006 23:40, Adam Kennedy wrote: Something like a clean_install metric. If there are any FAIL entries in CPAN Testers against the current version of your module, you lose a point. The PITA-based (what I'm thinking of calling) Vanilla Testers system is intended for a similar purpose. Test modules based on installation from scratch. With this focus on more-practical aspects, we can zero on the module within CPAN that are causing the most problem FAR more easily, and we know where attention needs to be placed. Let me save you the trouble of writing it to find the biggest problem right now: fairly broken automated testing systems that can't even *run* the Build.PL file *or* the compatibility Makefile.PL yet send FAIL reports anyway. Right now you might as well skip the check and assign a point based on rand() seeded by the current phase of the moon. At least that's not truly random. -- c
Re: Dependency trees was: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
I think this would be rad: - PPM becomes part of the perl core - All CPAN packages are built to into PPDs automatically on common platforms - PPM is extended to allow installing into non-root locations This would allow non-perl people to install perl packages much easier, without having to mess with the CPAN shell and running tests. It would also make installing CPAN packages into hosted environments much easier. Any thoughts? I think this would be incredibly bad, and a clear example of premature optimisation. If CPAN is installation from source, then binary packages will depend VERY heavily on the environment they are built in. With many many modules needing various external libraries in order to work, that integration needs to be done by the package management system of each environment. That means while PPMs work file on ActivePerl, they may NOT other place. The only guarantee the ActiveState PPM library provides for example is that it will work within ActivePerl. The same binary package doesn't work in different environments in any other language, and it doesn't work for us either. Binaries need to be built for Debian, or FreeBSD, or ActivePerl or whatever, it would be greatly overstepping our (the Perl language) mandate to dictate some form of standard packaging system for Perl applications that differs from the native packaging system for that environment that Python and C and C++ and Ruby and Scheme and Lisp and everything else uses. It's appropriate for ActiveState to build PPMs against the ActivePerl environment. It's not appropriate for us to do it in core Perl. What I'd like to see instead is suggestions on ways that we can improve Perl packages to make it easier for the various auto-packaging systems to do their job. If a Perl module needs libfoo then it should be stated in the metadata somewhere so that the binary packaging system can resolve that generalised dependency into the appropriate action for that environment. Adam K
Re: Dependency trees
My point is just that what makes PPM so good is that it doesn't futz about with compiling code and running tests. It just installs the code and goes home. But then so does apt-get install libfoo-perl. The installation is environment specific. It's just that ActiveState provides a relatively common environment in the form of ActivePerl that means they can provide pre-compiled binary libs. Adam K
Re: Test Script Best-Practices
James E Keenan wrote: Steffen Schwigon wrote: Quite often -l (to read from lib/) is enough, depending on your module build complexity. For -b you have to call ./Build before prove, which can be annoying and/or difficult to remember. I'll have to try that out. My modules all use MakeMaker rather than Module::Build. And I'm generally using 'prove' to trouble-shoot individual tests after I've already run 'make test' and identified which test files have failures. jimk Or $a_specific_perl_path Build in the case of other situations. Adam K
