Install python and moodlemlbackend package

[dmonllao]

No description provided.

[dmonllao]

I imagine that the patch would need to be cherry picked to each of the supported branches.

[dmonllao]

Correcting myself: this patch should be applied to *stretch branches. I've created #36 for jessie branches.

[dmonllao]

The patch has been amended to clear apt and pip caches.

[dmonllao]

As commented in #36 I would vote to integrate this in stretch and forget about #36. I am personally using moodle-docker exclusively for development and to integrate this issue and moodlehq/moodle-docker#90 would make things significantly easier for me.

[dmonllao]

I've just closed #35 (jessie) anything against integrating this patch?

How are we managing system upgrades? E.g. I start using docker today and I use the latest moodlemlbackend version (0.0.5). During Moodle 3.7 development cycle we release a new moodlemlbackend version (0.0.6) tests stop working because Moodle now requires moodlemlbackend 0.0.6. Is there a process to follow so my moodlemlbackend version gets updated?

[stronk7]

Hi,

after our recent conversations now that a "server" MDL-66004 is (going to be) available, it seems that we hardly* will be incorporating the backend to the php images and, instead, will use the server alternative to run those tests in our CI infrastructure (and also with moodle-docker).

So, we'll be continuously testing the backend via the server alternative. That leaves the local alternative not being tested. Only when some issue enforces it, or a recurring MDLQA asks for it it will be run.

Just thinking that, a probable alternative for this PR could be something like:

1. we create a shell script that asks:

• PHP version to use
• Python version to use.
• mlbackend version to use.

2. And then it magically, gets one of our php images as base and build a new one (locally, won't be sent to cocker registry ever) with the python and mlbackend versions installed. Then tests can be run and done.

3. Basically all we need is a Dockerfile (or script) that dynamically does that. And it would create images like 7.3-3.7.4-2.2.0(php, python, backend) for example.

4. Then they can be used to test local (within the custom docker image just created) without much problem. In fact surely we could add a job to make it also in CIs (and dispose the image once done).

So I think the code in this PR is valid... but, instead of adding it to the php-apache images... let's apply it within a utility generating those "custom" images.

100% and idea, happy to discuss.

• hardly: because it's going to be impossible to keep one image working for Moodle 3.5 to 4.1 if we do so, because the backend versions go advancing (as David commented above).

[scara]

Hello Everyone,
why not going on an hybrid path i.e. including the script within the mainstream adding the arguments Eloy described above and then run it within an instance i.e. the container, when required by the specific test execution?

It would be the same as running a phpunit session: the limit is when people run docker w/o root permissions since the script should install packages...
At the end, I think that Eloy's proposal makes sense if we want to be non-root-proof as told by @andrewnicols in other issues within the Moodle Docker Toolbox.

HTH,
Matteo