PLEASE... fix (PHPUnit) installation without maxima

[thepurpleblob]

Once again, I tried to configure Moodle for unit testing with the stack question in the codebase and, of course, it failed.

I eventually (because I remembered it existed) found...

define('QTYPE_STACK_TEST_CONFIG_PLATFORM', 'none');

....in another test install, but I couldn't find it in your docs, it's not in the readme and so on.

It's quite annoying - sorry. The stack plugin should not fail to install because it's requirements are not met. I don't think that's acceptable. Sorry for the moaning....

[sangwinc]

Howard,
This really is an edge case! Not having Maxima is normally a serious red-flag. The whole plugin will fail to do anything meaningful without Maxima. So, can I ask why you need to do this? We'll certainly facilitate useful situations, but currently we really did intend to make sure the PHP unit setup fails when you try to do this without Maxima. I'm happy do discuss this by email (C.J.Sangwin@ed.ac.uk) or a zoom call if it would help.

Just two things. First, adding a feature like this is work which I have to do. Second, adding a feature like this might lead to very serious problems when other people use this to disable a fail because they "just want the tests to pass" when Maxima is essential and we want to avoid this as well.

Thanks for your interest in STACK. I'll certainly help if I can,
Chris

[aharjula]

Also worth noting is that if you really want to keep your PHPUnit system free of Maxima, you can do so by setting the configuration to use a remote server-maxima, but then you need to have a separate MaximaPool or goemaxima setup. To do that, you need to set these and obviously have a proper address to your server, and that server needs to have the matching STACK version libraries/images:

define('QTYPE_STACK_TEST_CONFIG_PLATFORM',        'server');
define('QTYPE_STACK_TEST_CONFIG_MAXIMACOMMANDSERVER',   'http://10.10.10.12:80/MaximaPool/MaximaPool');

And that is what you would obviously do when testing a proper install, as it would need to be tested against the Maxima setup of that install, and a proper large install tends to be such that there is no Maxima on the Moodle nodes.

That being said, you either test with Maxima or you do not test at all. There is no STACK without Maxima.

[thepurpleblob]

Firstly, I'm keenly aware of not wanting to sound antagonistic - so, thanks for your interest.

I do all sorts of odds and ends of development with Moodle but our main code base includes Stack. 99% of the time, I have zero interest in running tests for Stack - or care whether it works or not... it's just there. I don't often have to build a new Moodle testing install but when I do - up comes this error. I then have to spend 20 mins finding the setting. I'm sure it can't just be me.

There are loads of other plugins that interact with external systems - if they don't find it and/or it's not set, they just shrug and go away.

So, I'm really just asking if stack could do the same without too much drama. If not, could you put the setting somewhere easy to find in your docs? I would suggest the readme.md file.

[timhunt]

If remembering to put define('QTYPE_STACK_TEST_CONFIG_PLATFORM', 'none'); in config.php works, then can't we make it so that if this is not defined, and if there is no maxima, then it behaves as if QTYPE_STACK_TEST_CONFIG_PLATFORM is set to none?

[sangwinc]

My only concern @timhunt is the number of support requests that start "I installed STACK, ran the unit tests on my setup, and nothing works" because they didn't install any access to Maxima (local or server). I get a lot of "I installed STACK, went live, and nothing works" for that reason already! I'm very happy to add, document and support the define('QTYPE_STACK_TEST_CONFIG_PLATFORM', 'none');
I want to support this, but it's an edge case for sure and I need to think through/discuss the consequences of a change in default. Very open to advice on standard/best practice here.

[aharjula]

My expectation is that if we don't, by default, test expecting Maxima, we will very likely see people claiming that all the tests passed, and they cannot, therefore, fathom why things do not work. So, the route of less drama to me seems to be to have the option to disable things but not have things disabled by default.

To me, it seems sane to think that if someone places STACK into their unit-test setup, then they might be interested in two things. Firstly, that STACK in its full form does not damage whatever else they have running and hopefully, secondly, that whatever those other things are, they do not mess up STACK. If neither of those is of interest, then they might as well either drop STACK entirely or toggle some disable switch, but they should be very well aware of that choice and its implications. We should not make that choice by default.

[thepurpleblob]

My point is that I'm NOT testing STACK... I'm just running the setup/install script for Moodle and then I'm testing a plugin that I'm working on. I'm not running the full tests; just the bit for my current work.

I want to use my Moodle build because there are other dependencies - pulling out individual plugins because they won't install is a big hassle.

But the thing is - in the nicest way - I don't care about STACK. At least not in this instance. I find it surprising that this isn't an issue for other plugin devs who also have STACK....

[sangwinc]

Well, after over 20 years of developing STACK I'm also surprised at the new things people really need to do! I think adding a documented option is the way forward here.

[thepurpleblob]

Yep - could just be me. This all started because I was in a rush and STACK got a LOT of abuse when it fell over :-D :-D

For full disclosure, I know nothing at all about STACK. Somebody else in my team supports it.