Installing/upgrading/testing should not output debugging or licence info.

[ewallah]

When initializing PHPUnit and Behat, or installing from the command line, the tool apcu outputs html code:

....
-->tool_apcu
++ <p>The tool_apcu admin report plugin includes a APCu management GUI which was built by the APCu developers. This APCu management GUI is just a small PHP file. Unfortunately, this file can't be shipped together with this plugin's code as its PHP license is incompatible with Moodle's GPL license.</p><p>Luckily, this Moodle installation had enough permissions to download and store the APCu management GUI file to your MOODLEDATA directly. It was downloaded from https://raw.githubusercontent.com/krakjoe/apcu/master/apc.php and stored to ..../tool_apcu/apcu.php.inc. After finishing the installation wizard, the tool_apcu plugin will work for you as expected.</p><p>Please note: With "license incompatibility", it is just meant that code licensed under the PHP license must not be hosted on moodle.org/plugins. For you as administrator, it's fine to download, host and run the APCu management GUI file and add it to your local installation of this Moodle plugin.</p> ++
++ Success (0.53 seconds) ++
-->tool_availabilityconditions
++ Success (0.09 seconds) ++
-->tool_behat
++ Success (0.16 seconds) ++
-->tool_brickfield
++ install.xml: Success (1.25 seconds) ++

Installing/upgrading/testing a plugin should not generate debugging info or license info.

[abias]

Hi @ewallah ,

thank you for raising this issue.
We have added this information to the installation wizard by purpose to inform the admin that a third party library / tool was downloaded and stored in Moodle.
It is mainly meant to be shown in the webbased installer, but we think it is not wrong to show this in the CLI installer.

Do you have any reference for the fact that "a plugin should not generate debugging info or license info"?

[ewallah]

Hi @abias,

First of all, the output is html in an environment that does not support html tags.

Next, this can be interesting additional information, but the info should not be part of the output during testing: it only makes debugging a lot more difficult. I think the readme file and/or the upgrade process is a more appropriate place for this info.

Last, but not least, you open the box of Pandora. What will happen when everybody starts adding publicity, SPAM, requests for donations, political statements, etc.