Re: CPANTS: suggestion for a new metric
In article [EMAIL PROTECTED], Nathan S. Haigh [EMAIL PROTECTED] wrote: A suggestion was to have different levels of strictness in Test::Kwalitee and have different sets of metrics being tested by default at each of those levels. However, I didn´t get into this and simply hard-coded some of the metrics to be skipped. I think that's a bit out of Test::Kwalitee's scope. It basically wraps each of the metric code refs in the testing framework and provides access to those things individually. It's then up to the user to decide which functions he wants to use. I'd leave Test::Kwalitee just like it is, feature-wise, and not have it dictate use or practice. Let it just provide the ability. Sub-classes and user classes, which probably have a much better chance of being maintained, should be the way to go. That's just my two cents though, and I'm willing to help clear out the current issues no matter which way it goes.
Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)
In article [EMAIL PROTECTED], chromatic [EMAIL PROTECTED] wrote: On Friday 01 June 2007 10:47:00 Andy Armstrong wrote: You could send them to me if you fancy? I'm guessing chromatic's pretty busy. I lost most of my outstanding patches a couple of weeks ago too, and only just noticed. If only we had some sort of community service where we could post patches and other people could see them :)
Re: CPANTS: suggestion for a new metric
Quoting brian d foy [EMAIL PROTECTED]: In article [EMAIL PROTECTED], Nathan S. Haigh [EMAIL PROTECTED] wrote: A suggestion was to have different levels of strictness in Test::Kwalitee and have different sets of metrics being tested by default at each of those levels. However, I didn´t get into this and simply hard-coded some of the metrics to be skipped. I think that's a bit out of Test::Kwalitee's scope. It basically wraps each of the metric code refs in the testing framework and provides access to those things individually. It's then up to the user to decide which functions he wants to use. I'd leave Test::Kwalitee just like it is, feature-wise, and not have it dictate use or practice. Let it just provide the ability. Sub-classes and user classes, which probably have a much better chance of being maintained, should be the way to go. That's just my two cents though, and I'm willing to help clear out the current issues no matter which way it goes. I agree, however, should an update be backward compatible or not? I mean, is it reasonable for someone to update their Test::Kwalitee module and then have them rewrite their tests such that they skip all tests that require a tar ball of their package etc? These are hard-coded to be skipped in the current version of Test::Kwalitee. This was one of the reasons I also hardcoded some metrics to be skipped. I´m pretty new to writing modules and tests, so I´m at your mercy with regards to best practices, but I too think that Test::Kwalitee should be able to test all metrics and it should be left to the user to decide which, if any metrics should be skipped. This could be easily changed in my existing patch to the current Test::Kwalitee module. It would have the ame behaviour as the current version for skipping metrics i.e.: Test::Kwalitee-import( tests = [ qw( -has_test_pod -has_test_pod_coverage ) ] ) On my return from holiday, who am I best sending my changes to? Nathan
Re: CPANTS: suggestion for a new metric
On 2 Jun 2007, at 11:33, Nathan S. Haigh wrote: On my return from holiday, who am I best sending my changes to? You could certainly send them to me. Maybe put them on rt.cpan.org too? -- Andy Armstrong, hexten.net
Re: CPANTS: suggestion for a new metric
On Saturday 02 June 2007 03:33:27 Nathan S. Haigh wrote: On my return from holiday, who am I best sending my changes to? The RT queue for Test::Kwalitee please, where I won't lose them. -- c
Test::Kwalitee (was: CPANTS: suggestion for a new metric)
On 1 Jun 2007, at 06:38, chromatic wrote: On Thursday 31 May 2007 19:08:27 Andy Armstrong wrote: On 1 Jun 2007, at 02:09, brian d foy wrote: I'll have some time next week if Andy doesn't beat me too it. I'm having a rummage around now :) chromatic: do you have a .perltidyrc you could send me? My muscle memory keeps reaching for the perltidy hot key that would convert your code to AndyPerl :) I use -ci=4 -bl these days. Not on Test::Kwalitee you didn't :) What's peoples' view on this? Test::Kwalitee currently exposes the known test types as methods. I can make it delve into Module::CPANTS::Analyse to find the tests that are actually available - but then what to do about the methods? I could * generate the methods dynamically based on the Kwalitee modules that are installed * generate only the current methods and add a new method test_against() (or whatever) that provides access to any named Kwalitee test * replace the generated methods with an AUTOLOAD handler In the test_against() or AUTOLOAD scenarios I could then make Kwalitee tests for which the module is unavailable skip automatically. Thoughts? -- Andy Armstrong, hexten.net
Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)
Quoting Andy Armstrong [EMAIL PROTECTED]: On 1 Jun 2007, at 06:38, chromatic wrote: On Thursday 31 May 2007 19:08:27 Andy Armstrong wrote: On 1 Jun 2007, at 02:09, brian d foy wrote: I'll have some time next week if Andy doesn't beat me too it. I'm having a rummage around now :) chromatic: do you have a .perltidyrc you could send me? My muscle memory keeps reaching for the perltidy hot key that would convert your code to AndyPerl :) I use -ci=4 -bl these days. Not on Test::Kwalitee you didn't :) What's peoples' view on this? Test::Kwalitee currently exposes the known test types as methods. I can make it delve into Module::CPANTS::Analyse to find the tests that are actually available - but then what to do about the methods? I could * generate the methods dynamically based on the Kwalitee modules that are installed * generate only the current methods and add a new method test_against() (or whatever) that provides access to any named Kwalitee test * replace the generated methods with an AUTOLOAD handler In the test_against() or AUTOLOAD scenarios I could then make Kwalitee tests for which the module is unavailable skip automatically. Thoughts? -- Andy Armstrong, hexten.net I recently made some simple changes to Test::Kwalitee so that it would test all the metrics provided by Module::CPANTS::Analyse. However, Chromitic hasn´t yet updated CPAN with these changes. I´m on holiday at the moment so I won´t be even more nerdy than I am at the moment )reading my works e-mails) by going into detail about the changes. Either Chromictic could get the changes through into CPAN or I can send you my changes on my return from holiday! Cheers Nathan
Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)
On 1 Jun 2007, at 18:41, Nathan S. Haigh wrote: I recently made some simple changes to Test::Kwalitee so that it would test all the metrics provided by Module::CPANTS::Analyse. However, Chromitic hasn´t yet updated CPAN with these changes. I´m on holiday at the moment so I won´t be even more nerdy than I am at the moment ) reading my works e-mails) by going into detail about the changes. Either Chromictic could get the changes through into CPAN or I can send you my changes on my return from holiday! You could send them to me if you fancy? I'm guessing chromatic's pretty busy. -- Andy Armstrong, hexten.net
Re: CPANTS: suggestion for a new metric
Quoting brian d foy [EMAIL PROTECTED]: On 5/31/07, Andy Armstrong [EMAIL PROTECTED] wrote: On 31 May 2007, at 21:42, brian d foy wrote: I've just been running cpants_lint.pl before I upload anything. If it doesn't say perfect, that fails. :) Yes, damn you :) I'll volunteer for a bit of poking of Test::Kwalitee if it doesn't need too much. I looked at the RT tickets. I think three of them can be closed immediately or re-assigned to Module::CPANTS::Analyse. Test::Kwalitee just does wraps taht module, so if people don't like how it does the work, it's not Test::Kwalitee's problem. One is a documentation patch, which is easy. The rest of them can probably be cleaned up by peeking into Module::CPANTS::Analyse to get the names and descriptions of the tests to build the %test_types hash in Test::Kwalitee. I think that's the only thing that needs an update. I think Module::CPANTS::Kwalitee-new-get_indicators_hash should take care of that. I already did this and sent Chromatic the changes, but he hasn´t yet got round to putting the changes on CPAN. One of the issues was that some metrics are for testing the tar ball which usually doesn´t make sense in a normal testing environment. In addition, thare are some other metrics which could be deemed optioanl. A suggestion was to have different levels of strictness in Test::Kwalitee and have different sets of metrics being tested by default at each of those levels. However, I didn´t get into this and simply hard-coded some of the metrics to be skipped. Nathan I'll have some time next week if Andy doesn't beat me too it. -- brian d foy [EMAIL PROTECTED] http://www.pair.com/~comdog/
Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)
Hi!
On Fri, Jun 01, 2007 at 03:23:14PM +0100, Andy Armstrong wrote:
Test::Kwalitee currently exposes the known test types as methods. I can
make it delve into Module::CPANTS::Analyse to find the tests that are
actually available - but then what to do about the methods?
Sorry, not a lot of time at the momemt, but I remember that somebody
(I think Nathan Haigh [EMAIL PROTECTED] ) already patched
Test::Kwalitee to dynamically figure out which metric to use.
But I'm only following this thread with 50% attention (sorry, YAPC takes
up all my tuits ATM), so might mix up things...
I could
* generate the methods dynamically based on the Kwalitee modules that
are installed
* generate only the current methods and add a new method test_against()
(or whatever) that provides access to any named Kwalitee test
* replace the generated methods with an AUTOLOAD handler
In the test_against() or AUTOLOAD scenarios I could then make Kwalitee
tests for which the module is unavailable skip automatically.
Thoughts?
--
Andy Armstrong, hexten.net
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)
On Friday 01 June 2007 10:47:00 Andy Armstrong wrote: You could send them to me if you fancy? I'm guessing chromatic's pretty busy. I lost most of my outstanding patches a couple of weeks ago too, and only just noticed. -- c
Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)
* Andy Armstrong [EMAIL PROTECTED] [2007-06-01 16:25]: I could * generate the methods dynamically based on the Kwalitee modules that are installed * generate only the current methods and add a new method test_against() (or whatever) that provides access to any named Kwalitee test * replace the generated methods with an AUTOLOAD handler In the test_against() or AUTOLOAD scenarios I could then make Kwalitee tests for which the module is unavailable skip automatically. Thoughts? Remember you can also combine options #1 and #3: generate methods at compile-time and use AUTOLOAD just for skipping. Would there be any provision for catching typos in any of these cases, though? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Test::Kwalitee (was: CPANTS: suggestion for a new metric)
* Andy Armstrong [EMAIL PROTECTED] [2007-06-02 03:40]: I know it's not as cute as the current interface - but cute can be surprising and I don't think a surprising interface is necessarily a good thing :) Agreed. It just depended on what you preferred; in case of a method per metric, generating methods + AUTOLOAD seemed to me to be the simplest option, as it would involve the least amount of conditional code. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CPANTS: suggestion for a new metric
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], chromatic [EMAIL PROTECTED] wrote: On Wednesday 30 May 2007 14:54:27 demerphq wrote: Er, so you want a metric to tell people about how their rejected upload to PAUSE isnt going to work right? That doesnt sound like a very useful metric. If PAUSE doesnt index it then you shouldnt test it as its already failed the most important metric there is. If I had time to fix Test::Kwalitee, you could run that test *before* uploading a distribution to PAUSE, or on DarkPAN code. Not all of CPANTS has to run against publicly-uploaded distributions. What does Test::Kwalitee need? Is it just fixing the stuff in RT or is there something else? I've just been running cpants_lint.pl before I upload anything. If it doesn't say perfect, that fails. :)
Re: CPANTS: suggestion for a new metric
On 31 May 2007, at 21:42, brian d foy wrote: I've just been running cpants_lint.pl before I upload anything. If it doesn't say perfect, that fails. :) Yes, damn you :) I'll volunteer for a bit of poking of Test::Kwalitee if it doesn't need too much. -- Andy Armstrong, hexten.net
Re: CPANTS: suggestion for a new metric
On 5/31/07, Andy Armstrong [EMAIL PROTECTED] wrote: On 31 May 2007, at 21:42, brian d foy wrote: I've just been running cpants_lint.pl before I upload anything. If it doesn't say perfect, that fails. :) Yes, damn you :) I'll volunteer for a bit of poking of Test::Kwalitee if it doesn't need too much. I looked at the RT tickets. I think three of them can be closed immediately or re-assigned to Module::CPANTS::Analyse. Test::Kwalitee just does wraps taht module, so if people don't like how it does the work, it's not Test::Kwalitee's problem. One is a documentation patch, which is easy. The rest of them can probably be cleaned up by peeking into Module::CPANTS::Analyse to get the names and descriptions of the tests to build the %test_types hash in Test::Kwalitee. I think that's the only thing that needs an update. I think Module::CPANTS::Kwalitee-new-get_indicators_hash should take care of that. I'll have some time next week if Andy doesn't beat me too it. -- brian d foy [EMAIL PROTECTED] http://www.pair.com/~comdog/
Re: CPANTS: suggestion for a new metric
On 1 Jun 2007, at 02:09, brian d foy wrote: I'll have some time next week if Andy doesn't beat me too it. I'm having a rummage around now :) chromatic: do you have a .perltidyrc you could send me? My muscle memory keeps reaching for the perltidy hot key that would convert your code to AndyPerl :) -- Andy Armstrong, hexten.net
Re: CPANTS: suggestion for a new metric
On Thursday 31 May 2007 19:08:27 Andy Armstrong wrote: On 1 Jun 2007, at 02:09, brian d foy wrote: I'll have some time next week if Andy doesn't beat me too it. I'm having a rummage around now :) chromatic: do you have a .perltidyrc you could send me? My muscle memory keeps reaching for the perltidy hot key that would convert your code to AndyPerl :) I use -ci=4 -bl these days. -- c
Re: CPANTS: suggestion for a new metric
On Wednesday 30 May 2007 14:54:27 demerphq wrote: Er, so you want a metric to tell people about how their rejected upload to PAUSE isnt going to work right? That doesnt sound like a very useful metric. If PAUSE doesnt index it then you shouldnt test it as its already failed the most important metric there is. If I had time to fix Test::Kwalitee, you could run that test *before* uploading a distribution to PAUSE, or on DarkPAN code. Not all of CPANTS has to run against publicly-uploaded distributions. -- c
Re: CPANTS: suggestion for a new metric
demerphq wrote: On 5/26/07, Andreas J. Koenig [EMAIL PROTECTED] wrote: AFAIK it is not Archive::Tar either. I have not found out which compression software packages do it right and which do it wrong. I have communicated with several authors about it but being Windows users, they do not know it either. It would be nice to know tho. If only so as to know what to avoid. GNU tar on Windows, I think. At least, pointing out the GNUish --mode switch has helped people to fix it whenever I've muttered at them about it. But everybody should know that PAUSE cannot index these beasts anyway and sends mail to the authors that it cannot read the contents of the distro ... Which makes me wonder why David complained about this issue at... Because I test *everything* that the PAUSE tells cpan-testers about, which includes unindexable distributions. Could it be that it actually *is* his decompression software? No. My tar program faithfully replicates the permissions in the file I feed to it. -- David Cantrell
CPANTS: suggestion for a new metric
Some modules' tarballs don't set the x bit on directories, which makes it impossible for a non-root user to run Makefile.PL or the module's tests. The usual cause is that the author suffers from Windows, and the fix is to use '--mode 755' when creating the tarball. I think it would be a good idea for CPANTS to check that directories have the x bits set. This would either be a new metric, or could be rolled into 'extracts_nicely', or could be combined with 'no_symlinks' and called 'uses_portable_filesystem_features' or something similar. -- David Cantrell
Re: CPANTS: suggestion for a new metric
* David Cantrell [EMAIL PROTECTED] [2007-05-26 16:45]: I think it would be a good idea for CPANTS to check that directories have the x bits set. ++ This would either be a new metric +=0 or could be rolled into 'extracts_nicely' ++ or could be combined with 'no_symlinks' and called 'uses_portable_filesystem_features' or something similar. -- It doesn’t have to do with filesystem features, it has to do with OS permission semantics. You can mount FAT32 and NTFS in unixoid systems and likewise mount ext2/3 in Windows, and a sufficiently abled tool could then correctly extract archives preserving non- portable features, but the permission semantics don’t carry over correctly anyway because the respective kernels are not able to convey them. The `extracts_nicely` metric is the right place for this, IMO. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CPANTS: suggestion for a new metric
On 5/26/07, David Cantrell [EMAIL PROTECTED] wrote: Some modules' tarballs don't set the x bit on directories, which makes it impossible for a non-root user to run Makefile.PL or the module's tests. The usual cause is that the author suffers from Windows, and the fix is to use '--mode 755' when creating the tarball. Can you explain this please? Why would the lack of a set x bit on a directory prevent you from doing perl Makefile.PL make make test Is this simply so you dont have to type 'perl'? cheers Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: CPANTS: suggestion for a new metric
* demerphq [EMAIL PROTECTED] [2007-05-26 17:35]: Can you explain this please? Why would the lack of a set x bit on a directory prevent you from doing perl Makefile.PL make make test Yes. Is this simply so you dont have to type 'perl'? No. The x bit on a directory determines whether you can resolve paths that cross it. ~ $ cd Proc-Fork ~/Proc-Fork $ chmod -x lib ~/Proc-Fork $ perl Build.PL Can't find file lib/Proc/Fork.pm to determine version at \ /usr/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm line 937. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CPANTS: suggestion for a new metric
On 5/26/07, A. Pagaltzis [EMAIL PROTECTED] wrote: * demerphq [EMAIL PROTECTED] [2007-05-26 17:35]: Can you explain this please? Why would the lack of a set x bit on a directory prevent you from doing perl Makefile.PL make make test Yes. Im assuming this means Yes it prevents this (Excessive terseness)-- Is this simply so you dont have to type 'perl'? No. The x bit on a directory determines whether you can resolve paths that cross it. ~ $ cd Proc-Fork ~/Proc-Fork $ chmod -x lib ~/Proc-Fork $ perl Build.PL Can't find file lib/Proc/Fork.pm to determine version at \ /usr/lib/perl5/site_perl/5.8.8/Module/Build/Base.pm line 937. Ok. Thanks. BTW, id say that if this is an issue for Unix users then they should file a bug with the people that wrote their decompression software and/or installer software. I dont see it as being my problem as a Win32 developer at all. Im sympathetic to the annoyance it causes but to me its like opening a book written in a language you dont read and complaining that it isnt written in one you do. I mean if Win32 doesnt even support this concept how is it my problem what your software does when unpacking? Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: CPANTS: suggestion for a new metric
On 26 May 2007, at 18:16, demerphq wrote: I dont see it as being my problem as a Win32 developer at all. Im sympathetic to the annoyance it causes but to me its like opening a book written in a language you dont read and complaining that it isnt written in one you do. I mean if Win32 doesnt even support this concept how is it my problem what your software does when unpacking? Lack of attention to detail? Supposed to work on any platform but doesn't? As a Win32 developer you have to appreciate that quite a lot of the Perl stuff you use (including Perl itself possibly) wouldn't exist if Win32 were the only OS in the World. -- Andy Armstrong, hexten.net
Re: CPANTS: suggestion for a new metric
On 5/26/07, A. Pagaltzis [EMAIL PROTECTED] wrote: * demerphq [EMAIL PROTECTED] [2007-05-26 19:20]: BTW, id say that if this is an issue for Unix users then they should file a bug with the people that wrote their decompression software and/or installer software. It's the decompression software's fault that it correctly preserves the data in the archive when decompressing?! Are you serious? Sorry, but it is *the _compression_ software's* bug. Fine, then what do i do about it? File a bug with Archive::Tar (maintained by a non windows programmer)? I dont see it as being my problem as a Win32 developer at all. Im sympathetic to the annoyance it causes but to me its like opening a book written in a language you dont read and complaining that it isnt written in one you do. I mean if Win32 doesnt even support this concept how is it my problem what your software does when unpacking? Tarballs are a Unix concept and use Unix permission semantics. Win32 developers creating tarballs are writing books in a language they don't speak. Then they get annoyed that native (or fluid) speakers of the language complain when their books are full of mistakes. (What a silly metaphor… but anyway.) Ok fair enough. I sit corrected. Sorry, you're wrong. I'm sorry if the silly Unix people are grating on your nerves, but they're right. Ok im wrong, and yes comments like suffering from windows do grate on my nerves. Maybe ill just upload my files in zip format from now on only, then its not my problem anymore right? Would that be better? Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: CPANTS: suggestion for a new metric
On 26 May 2007, at 18:45, demerphq wrote: Maybe ill just upload my files in zip format from now on only, then its not my problem anymore right? Would that be better? That would be fine. You know - you've kind of tickled a raw nerve here. One of the very few reasons I maintain a Windows box here and endure the pain (for me - subjective I know) that goes with it is so I can test my modules against Win32. And the only reason I bang my head off Win32 related problems is because I have a deeply held conviction that my stuff should - if possible - work on any platform Perl supports. I honestly don't think - given the hassle that supporting Win32 is for so many people who otherwise wouldn't touch it - that you have much room to bitch about a Unix specific problem. -- Andy Armstrong, hexten.net
Re: CPANTS: suggestion for a new metric
On 5/26/07, Andy Armstrong [EMAIL PROTECTED] wrote: On 26 May 2007, at 18:45, demerphq wrote: Maybe ill just upload my files in zip format from now on only, then its not my problem anymore right? Would that be better? That would be fine. You know - you've kind of tickled a raw nerve here. did you all wake up on the wrong side ? Could you please calm down? Gabor
Re: CPANTS: suggestion for a new metric
On 5/26/07, Andy Armstrong [EMAIL PROTECTED] wrote: On 26 May 2007, at 18:45, demerphq wrote: Maybe ill just upload my files in zip format from now on only, then its not my problem anymore right? Would that be better? That would be fine. Fine then. The fact that ExtUtils make dist automatically produces a .tar.gz and the fact that Archive::Tar does not do the right thing is not exactly my fault however. You know - you've kind of tickled a raw nerve here. As did David in his original post for me. One of the very few reasons I maintain a Windows box here and endure the pain (for me - subjective I know) that goes with it is so I can test my modules against Win32. And the only reason I bang my head off Win32 related problems is because I have a deeply held conviction that my stuff should - if possible - work on any platform Perl supports. Yes i agree with this as well. I go to similar lengths to ensure my code works on *nix. And yes i appreciate your efforts, although to the best of my knowledge ive never directly benefitted from them. I honestly don't think - given the hassle that supporting Win32 is for so many people who otherwise wouldn't touch it - that you have much room to bitch about a Unix specific problem. I was out of line in how i put things. I apologise. yves -- perl -Mre=debug -e /just|another|perl|hacker/
Re: CPANTS: suggestion for a new metric
On 26 May 2007, at 19:03, Gabor Szabo wrote: did you all wake up on the wrong side ? Could you please calm down? I can confirm that I'm spectacularly calm :) -- Andy Armstrong, hexten.net
Re: CPANTS: suggestion for a new metric
On 26 May 2007, at 19:06, demerphq wrote: I was out of line in how i put things. I apologise. Thanks Yves. I /still/ think it's pretty cool that basically we're all friends :) -- Andy Armstrong, hexten.net
Re: CPANTS: suggestion for a new metric
# from demerphq # on Saturday 26 May 2007 10:45 am: Sorry, but it is *the _compression_ software's* bug. Fine, then what do i do about it? File a bug with Archive::Tar (maintained by a non windows programmer)? This should be properly handled by the dist action of any sufficiently modern Module::Build or Module::Install or ExtUtils::MakeMaker. If it isn't, that's where the bug is. --Eric -- Atavism n: The recurrence of any peculiarity or disease of an ancestor in a subsequent generation, usually due to genetic recombination. --- http://scratchcomputing.com ---
Re: CPANTS: suggestion for a new metric
* Andy Armstrong [EMAIL PROTECTED] [2007-05-26 19:50]: One of the very few reasons I maintain a Windows box here and endure the pain (for me - subjective I know) that goes with it is so I can test my modules against Win32. So do I. And yeah, I find it painful too. But it’s not open for debate. Btw, if any people with strong Win32 skills can help me stop Proc::Fork from “segfaulting” on Windows, I’d appreciate it. I tried a whole bunch of things but ran out of ideas and it’s still broken. I asked around but no one seemed to know any better. * demerphq [EMAIL PROTECTED] [2007-05-26 20:10]: Fine then. The fact that ExtUtils make dist automatically produces a .tar.gz and the fact that Archive::Tar does not do the right thing is not exactly my fault however. No – *but* it does affect users that are interested in such brokenly packaged modules, so deducting Kwalitee is the correct thing to do IMO. Even if MakeMaker or Archive::Tar or whatever it is that’s broken were fixed, not every author uses the same tools, and someone might decide to use something different without knowing it’s broken. Again then it’s the author who needs to fix his distro, even though he couldn’t know that the tool he used was broken and isn’t to blame for that. So again – having this check in the metrics would serve a useful purpose. I’m not singling out Win32 people, btw. If a similar error was likely to be a Unix-based author’s gaffe, I’d still advocate a check. The collective goal is to make things that work as painlessly as possible for as many people as possible. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: CPANTS: suggestion for a new metric
On Sat, 26 May 2007 20:06:18 +0200, demerphq [EMAIL PROTECTED] said: On 5/26/07, Andy Armstrong [EMAIL PROTECTED] wrote: On 26 May 2007, at 18:45, demerphq wrote: Maybe ill just upload my files in zip format from now on only, then its not my problem anymore right? Would that be better? That would be fine. Fine then. You do not have to change anything, Yves. Your tarballs were all fine as far as I know. Do not switch to zip format, please, without a reason. While ZIP has several significant advantages over TAR.GZ, it is inferior in compression metrics. CPAN is not fond of seeing zip files because they usually are 10-30 percent bigger. The fact that ExtUtils make dist automatically produces a .tar.gz and the fact that Archive::Tar does not do the right thing is not exactly my fault however. AFAIK it is not Archive::Tar either. I have not found out which compression software packages do it right and which do it wrong. I have communicated with several authors about it but being Windows users, they do not know it either. On new metrics: I agree with the OP that software packaged with absurd permission bits offends kwality. But everybody should know that PAUSE cannot index these beasts anyway and sends mail to the authors that it cannot read the contents of the distro and that they need to make a new upload when they want to be indexed. -- andreas
