Skip Menu |

This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics
Id: 127865
Status: open
Priority: 0/
Queue: CPAN
People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 2.21-TRIAL
Fixed in: (no value)
Attachments
Dockerfile

History Show all quoted text
  Fri Nov 30 12:15:29 2018 SREZIC [...] cpan.org - Ticket created
Subject: install_tested may install distributions not listed in is_tested
It seems that install_tested installs also optional prerequisites (if recommends_policy is set to a true value), but this is not previously reported by is_tested. Attached is a Dockerfile which reproduces the problem with CPAN 2.21-TRIAL (but earlier versions are probably also affected --- I encountered this problem also with 2.16, I think). Here are the interesting lines of the output: ... Result: PASS MARIOROY/MCE-1.837.tar.gz /usr/bin/make test -- OK Call now is_tested: Fri Nov 30 17:09:44 2018 /root/.cpan/build/MCE-1.837-0 Call now install_tested: install_tested: Running for MARIOROY/MCE-1.837.tar.gz Running install for module 'Sereal::Encoder' Fetching with HTTP::Tiny: ... That is: MCE was tested (and just MCE), then is_tested correctly reports that only this distribution was tested, and install_tested continues with building and testing other modules... What I would expect: Either: install_tested only installs what was reported by is_tested, and ignores the recommends_policy setting. Or: "test Something" would test the optional prereqs in the same phase as normal prereqs (but ignores failures of these prereqs). Then is_tested would probably report exactly the same what would be installed later with install_tested.
Subject: Dockerfile
Download Dockerfile
application/octet-stream 838b

Message body not shown because it is not plain text.

  Sun Dec 02 08:58:45 2018 ANDK [...] cpan.org - Correspondence added
I see your point, but I believe there is a way to understand and justify the current behaviour. If `recommends` is strictly a recommendation for the installation phase, then the recommended modules do not play a role during testing. They start to be relevant only when the user decides to install a distro that recommends them. I would also argue that the recommends_policy setting can change at runtime, so we should not pay attention to it during a test command.
  Sun Dec 02 08:58:46 2018 The RT System itself - Status changed from 'new' to 'open'
  Mon Dec 03 08:15:58 2018 SREZIC [...] cpan.org - Correspondence added
On 2018-12-02 08:58:45, ANDK wrote: Show quoted text
> I see your point, but I believe there is a way to understand and > justify the current behaviour. If `recommends` is strictly a > recommendation for the installation phase, then the recommended > modules do not play a role during testing. They start to be relevant > only when the user decides to install a distro that recommends them. I > would also argue that the recommends_policy setting can change at > runtime, so we should not pay attention to it during a test command.
Maybe this issue should be split into two issues. The original issue is just the surprising behavior: is_tested shows what is currently tested. install_tested installs more than is_tested reported. "surprising" is something undesirable, and IMHO qualifies as a bug. It could be alleviated by documenting this behavior, but this would by only the 2nd best solution. My comment about handling recommended prereqs differently was just a proposal for an easy fix. But I am also in favor of changing the current handling for other reasons, but this could go into another issue.
  Mon Dec 24 07:56:17 2018 ANDK [...] cpan.org - Correspondence added
Can you be more specific? Which easy fix do you have in mind? Which other reasons? How would the other reasons then influence the decision about the easy fix?
  Sun Dec 30 06:31:55 2018 SREZIC [...] cpan.org - Correspondence added
On 2018-12-24 07:56:17, ANDK wrote: Show quoted text
> Can you be more specific? Which easy fix do you have in mind?
"Easy" was probably too optimistic. It's easy to say it in words: do the optional prereq installation in the same phase like the normal prereq installation. But then the questions and complications arise: should a failure of testing/installing an optional prereq fail the installation of the initial module? This would be a change to the current behavior --- IMHO not a bad one, but maybe authors already rely on the current behavior. Or should failures of optional prereqs be handled gracefully --- but in this case it's necessary to keep track of the status of the dependency (optional or not), and do it right if another dependency wants the optional prereq to be a mandatory one etc. Show quoted text
> Which > other reasons? How would the other reasons then influence the decision > about the easy fix?
Simply because we're losing test coverage with the current approach. The initial module could have test cases which are only active if the optional module is already installed. Or the optional module could trigger a different code path (say, it could provide an XS implementation instead of a PP one).
  Sat Jan 05 07:28:46 2019 ANDK [...] cpan.org - Correspondence added
"Recommends" is often used to avoid circular dependencies: - Date::Calc::XS depends on Date::Calc Date::Calc recommends Date::Calc::XS, - HTML::FormatText depends on HTML::Element HTML::Element recommends HTML::FormatText, - MouseX::ConfigFromFile depends on MouseX::Types::Path::Class MouseX::Types::Path::Class recommends MouseX::Getopt MouseX::Getopt depends on MouseX::ConfigFromFile MouseX::Getopt depends on MouseX::SimpleConfig MouseX::SimpleConfig depends on MouseX::ConfigFromFile This underpins that the term "optional prerequisites" is a misleading term. And this is probably why the two policies were called recommends_policy and suggests_policy. I believe the maximization of test coverage has many aspects that need to be shifted to some other level of monitoring CPAN, e.g. repeating tests after installating stuff.