Re: unsatisfied configure_requires in perl 5.12.3?
On Tue, Apr 22, 2014 at 09:46:26AM -0700, Karen Etheridge wrote: On Tue, Apr 22, 2014 at 12:51:02PM +0100, David Cantrell wrote: A 'FAIL' result doesn't mean this code is broken. It doesn't even mean this code is broken on this version of perl and this OS. It means it didn't pass its tests on this particular setup. That's why in cpXXXan I don't pay any attention to failures at all. Are you saying you only look for the presence of a PASS, not the absence of a FAIL, when considering whether to index a distribution for a particular cpXXXan? Yup. Consider, for example, a report like this: http://www.cpantesters.org/cpan/report/03359184-b19f-3f77-b713-d32bba55d77f where the tests failed because they were run on a machine without enough memory available. It isn't possible to automatically and reliably categorise failure reports into valid and invalid^W^W^Wuseful and not useful for users, so I don't even try. But we can be pretty damned certain that *pass* reports are correct. -- David Cantrell | A machine for turning tea into grumpiness Compromise: n: lowering my standards so you can meet them
Re: unsatisfied configure_requires in perl 5.12.3?
On Tue, Apr 22, 2014 at 09:48:14AM -0700, Karen Etheridge wrote: On Tue, Apr 22, 2014 at 04:50:03PM +0300, Alexandr Ciornii wrote: I've investigated this problem (checking perllocal.pod helped) and caught Task-Git-LongList1 doing installation by itself, so even test of this module installs some modules. Ugh, those Task-Git-LongList* modules look like excellent candidates to put in distroprefs as never test. How useless! And Bundle-Git-LongList* as well. Nothing depends on them. -- David Cantrell | Hero of the Information Age Safety tip: never strap firearms to a hamster
Re: unsatisfied configure_requires in perl 5.12.3?
Hi Karen, Going back to your original thought... (Other testers: should we put a minimum bar on the acceptable version of CPAN.pm/CPANPLUS for smoking, if we know that earlier versions are guaranteed to produce bad results? I've thought about adding a check right in Makefile.PL for the version of the cpan client (for information purposes only - that wouldn't affect the outcome of the build) -- what versions should I be looking for?) Specifically for the smokers, this might not be a bad thing. However, it can still be nice to see whether the base install (including the toolchain) is capable of getting a PASS report. Sadly, it isn't easy to detect this currently, so that the reports site could selectively allow you to ignore FAILs on base installs, where a newer part of the toolchain exists. If we were to recommend a minimum version for each part of the toolchain (and smoke chain too), I think this should be a page on the CPAN Testers Wiki, that we can refer testers to. Particularly new testers. However, what are the minimum versions? Would suggestions be made based on the perl version, or a blanket minimum version? Recommendation would need to cover all 3 main installers and associate smoker clients, as well as the transport tools. Does anyone have any minimum recommendations to start with (aside from the latest version)? Thanks, Barbie. -- Birmingham.pm - http://birmingham.pm.org CPAN Testers - http://cpantesters.org YAPC Surveys - http://yapc-surveys.org Perl Jam - http://perljam.info
Re: unsatisfied configure_requires in perl 5.12.3?
It might also vary by platform. David On Wed, Apr 23, 2014 at 9:55 AM, Barbie bar...@missbarbell.co.uk wrote: Hi Karen, Going back to your original thought... (Other testers: should we put a minimum bar on the acceptable version of CPAN.pm/CPANPLUS for smoking, if we know that earlier versions are guaranteed to produce bad results? I've thought about adding a check right in Makefile.PL for the version of the cpan client (for information purposes only - that wouldn't affect the outcome of the build) -- what versions should I be looking for?) Specifically for the smokers, this might not be a bad thing. However, it can still be nice to see whether the base install (including the toolchain) is capable of getting a PASS report. Sadly, it isn't easy to detect this currently, so that the reports site could selectively allow you to ignore FAILs on base installs, where a newer part of the toolchain exists. If we were to recommend a minimum version for each part of the toolchain (and smoke chain too), I think this should be a page on the CPAN Testers Wiki, that we can refer testers to. Particularly new testers. However, what are the minimum versions? Would suggestions be made based on the perl version, or a blanket minimum version? Recommendation would need to cover all 3 main installers and associate smoker clients, as well as the transport tools. Does anyone have any minimum recommendations to start with (aside from the latest version)? Thanks, Barbie. -- Birmingham.pm - http://birmingham.pm.org CPAN Testers - http://cpantesters.org YAPC Surveys - http://yapc-surveys.org Perl Jam - http://perljam.info -- David Golden x...@xdg.me Twitter/IRC: @xdg
Re: unsatisfied configure_requires in perl 5.12.3?
Hi
On 23/04/14 23:55, Barbie wrote:
Hi Karen,
If we were to recommend a minimum version for each part of the toolchain
(and smoke chain too), I think this should be a page on the CPAN Testers
Would this be implemented with makefiles containing smoking_requires =
{...}.
--
Ron Savage
savage.net.au
Re: unsatisfied configure_requires in perl 5.12.3?
On Mon, Apr 21, 2014 at 11:25 PM, Daniel Staal dst...@usa.net wrote: In general, I'm against pushing that check into the testing framework - there are occasional situations where you can find yourself using truly ancient versions of perl and tools, and I would prefer to have requirements explicitly declared where I can check them than implicitly assumed. I agree, mostly. I do think that CPAN Testers should generally run a relatively modern toolchain, including CPAN clients. Testing whether something can pass tests on a bog-standard ancient Perl is not really useful data for maintainers because for a long, long time, the answer to I can't install is upgrade your toolchain. David -- David Golden x...@xdg.me Twitter/IRC: @xdg
Re: unsatisfied configure_requires in perl 5.12.3?
On Tue, Apr 22, 2014 at 07:48:35AM -0400, David Golden wrote: On Mon, Apr 21, 2014 at 11:25 PM, Daniel Staal dst...@usa.net wrote: In general, I'm against pushing that check into the testing framework - there are occasional situations where you can find yourself using truly ancient versions of perl and tools, and I would prefer to have requirements explicitly declared where I can check them than implicitly assumed. I do think that CPAN Testers should generally run a relatively modern toolchain, including CPAN clients. Testing whether something can pass tests on a bog-standard ancient Perl is not really useful data for maintainers because for a long, long time, the answer to I can't install is upgrade your toolchain. It is, however, useful for people wanting to use modules. -- David Cantrell | http://www.cantrell.org.uk/david What a lovely day! Now watch me spoil it for you.
Re: unsatisfied configure_requires in perl 5.12.3?
On Tue, Apr 22, 2014 at 8:03 AM, David Cantrell da...@cantrell.org.uk wrote: toolchain, including CPAN clients. Testing whether something can pass tests on a bog-standard ancient Perl is not really useful data for maintainers because for a long, long time, the answer to I can't install is upgrade your toolchain. It is, however, useful for people wanting to use modules. Not really. They can't easily differentiate between problems that could be fixed if they upgraded their toolchain and problems inherent to the module itself. Showing that PASS is possible (if only they upgraded their toolchain) would seem to be much more useful as it indicates that using a module is achievable.
Re: unsatisfied configure_requires in perl 5.12.3?
On Tue, Apr 22, 2014 at 12:51:02PM +0100, David Cantrell wrote: A 'FAIL' result doesn't mean this code is broken. It doesn't even mean this code is broken on this version of perl and this OS. It means it didn't pass its tests on this particular setup. That's why in cpXXXan I don't pay any attention to failures at all. Are you saying you only look for the presence of a PASS, not the absence of a FAIL, when considering whether to index a distribution for a particular cpXXXan? Given a combination of perl/OS that a dist normally passes on, there are all kinds of reasons that it might occasionally fail, and I doubt that an old CPAN.pm is even the most common. But it is one of the easiest to diagnose if someone is using the test reports properly and actually looking at the details. I must take issue with easiest. I've been looking at cpantesters reports for quite some time as an active maintainer of some commonly-used distributions, and it's nowhere near easy trying to determine the source of errors in some reports. On Mon, Apr 21, 2014 at 11:25:48PM -0400, Daniel Staal wrote: If you truly need a minimum version of CPAN, declare it. You can set a version of CPAN in the prereqs like you can set any other module. No specific CPAN client is needed to install any distribution. However, if configure_requires prereqs are not going to be detected and fulfilled, the installation will fail. Incidentally, the answer to one of my original questions what version of CPAN.pm is known to not fulfill configure_requires is 1.94_55 (and lower). (Thanks, Graham Knop!) On Tue, Apr 22, 2014 at 09:23:28AM -0400, David Golden wrote: It is, however, useful for people wanting to use modules. Not really. They can't easily differentiate between problems that could be fixed if they upgraded their toolchain and problems inherent to the module itself. This is the dilemma I'm facing when reading incoming FAIL reports -- if I can't tell what the reason for the failure is, I can't know if it's something in the distribution's code itself, or a (solvable) problem with the installation system. If I as an author can't interpret the report, how is a more casual user supposed to tell?
Re: unsatisfied configure_requires in perl 5.12.3?
On Tue, Apr 22, 2014 at 04:50:03PM +0300, Alexandr Ciornii wrote: I've investigated this problem (checking perllocal.pod helped) and caught Task-Git-LongList1 doing installation by itself, so even test of this module installs some modules. Ugh, those Task-Git-LongList* modules look like excellent candidates to put in distroprefs as never test. How useless!
Re: unsatisfied configure_requires in perl 5.12.3?
--As of April 22, 2014 9:23:28 AM -0400, David Golden is alleged to have said: On Tue, Apr 22, 2014 at 8:03 AM, David Cantrell da...@cantrell.org.uk wrote: toolchain, including CPAN clients. Testing whether something can pass tests on a bog-standard ancient Perl is not really useful data for maintainers because for a long, long time, the answer to I can't install is upgrade your toolchain. It is, however, useful for people wanting to use modules. Not really. They can't easily differentiate between problems that could be fixed if they upgraded their toolchain and problems inherent to the module itself. Showing that PASS is possible (if only they upgraded their toolchain) would seem to be much more useful as it indicates that using a module is achievable. --As for the rest, it is mine. I saw my point as completely orthogonal to the reports, actually. CPAN collects reports from Perl users to see if modules pass their tests - whether those users are running the smoke toolchain is unknown. Most probably are, but you can send in a report anytime you are using CPAN, if you wish. I actually expect most smokers to be running a fairly recent perl, just because it's the type of place where it's usually good to run updates. The ancient versions of perl are probably running on secured isolated boxes where upgrading is procedurally impossible. Either way, the point of the reports is present a sampling of perl installs and how well they fare with each module. The prereqs are the lists of modules and versions the author lists as necessary for the proper operation of the module. You can check them against your local install however you wish - CPAN will do it for you, if you happen to be using CPAN, but they are available for your use however you need to use them. Anyone can send a CPAN test report, and anyone can install a module without CPAN. Therefore, I don't think the prereq list (for install) should take into account the CPAN smoke test infrastructure (a subset of the CPAN testers). Changing the CPAN Smoke Test architecture in an effort to present a 'modern' Perl to module authors only encourages them to rely on that modern Perl without asking for it - which will cause surprise and problems when they don't get it for some case, for both the author and the user of the module. We have an explicit prereq system. Use it. It will help both author and user. *Let me see what you are relying on, don't just expect it to be available.* That includes the toolchain: if you need a modern toolchain, say so. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: unsatisfied configure_requires in perl 5.12.3?
--As of April 22, 2014 9:46:26 AM -0700, Karen Etheridge is alleged to have said: On Mon, Apr 21, 2014 at 11:25:48PM -0400, Daniel Staal wrote: If you truly need a minimum version of CPAN, declare it. You can set a version of CPAN in the prereqs like you can set any other module. No specific CPAN client is needed to install any distribution. However, if configure_requires prereqs are not going to be detected and fulfilled, the installation will fail. I get what you are saying (CPAN is *never* needed, I get that), but if you really feel that way why are we having this discussion? You suggested the solution to some failures was to upgrade a module to a more recent version - My point is that if you think that's necessary, why not say so in your module? (Where others can see that requirement, and fulfil it on a case-by-case basis, instead of a large scale toolchain modification for all users.) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: unsatisfied configure_requires in perl 5.12.3?
Hello It is not possible to require CPAN client version: 1. It is not known which CPAN client will be used, there are 3 of them 2. Even if correct CPAN client is required and was installed, it will not be used to install/test this module because CPAN clients do not restart automatically. And even if it would work, in this case it would not help, because it was problem with auto_install in other module. 2014-04-22 22:17 GMT+03:00 Daniel Staal dst...@usa.net: --As of April 22, 2014 9:46:26 AM -0700, Karen Etheridge is alleged to have said: On Mon, Apr 21, 2014 at 11:25:48PM -0400, Daniel Staal wrote: If you truly need a minimum version of CPAN, declare it. You can set a version of CPAN in the prereqs like you can set any other module. No specific CPAN client is needed to install any distribution. However, if configure_requires prereqs are not going to be detected and fulfilled, the installation will fail. I get what you are saying (CPAN is *never* needed, I get that), but if you really feel that way why are we having this discussion? You suggested the solution to some failures was to upgrade a module to a more recent version - My point is that if you think that's necessary, why not say so in your module? (Where others can see that requirement, and fulfil it on a case-by-case basis, instead of a large scale toolchain modification for all users.) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- -- Alexandr Ciornii, http://chorny.net
Re: unsatisfied configure_requires in perl 5.12.3?
On Tue, Apr 22, 2014 at 3:17 PM, Daniel Staal dst...@usa.net wrote: My point is that if you think that's necessary, why not say so in your module? (Where others can see that requirement, and fulfil it on a case-by-case basis, instead of a large scale toolchain modification for all users.) It's a chicken and egg situation. Before Perl v5.10.1, CPAN clients that shipped with Perl did not support configure_requires. Presumably, once at least those versions of the clients are installed, any distribution can configure_requires (or use other prereqs) to specify and get what it wants. And, as we occasionally see, even still the toolchain is buggy. A PASS report from an updated toolchain tells people what is possible to achieve. A FAIL report from an outdated toolchain tells people either that the distribution is bad or that the toolchain is broken. Ambiguous causes of failure are a problem because it takes extra human effort to disambiguate -- effort which is often in short supply. Providing an updated toolchain as much as possible for smoking optimizes for people's time. The more people find CPAN testers to be a waste of time, the less attention they will pay to the information it generates. David
