moodle-php-apache icon indicating copy to clipboard operation
moodle-php-apache copied to clipboard

Published 20 hours ago • verified publisher icon moodlehq

Install python and moodlemlbackend package

Open dmonllao opened this issue 5 years ago • 7 comments

dmonllao avatar Dec 10 '18 10:12 dmonllao

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

dmonllao avatar Dec 10 '18 10:12 dmonllao

Correcting myself: this patch should be applied to *stretch branches. I've created https://github.com/moodlehq/moodle-php-apache/pull/36 for jessie branches.

dmonllao avatar Dec 10 '18 11:12 dmonllao

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

dmonllao avatar Dec 10 '18 16:12 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 https://github.com/moodlehq/moodle-docker/pull/90 would make things significantly easier for me.

dmonllao avatar Jan 30 '19 15:01 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?

dmonllao avatar Feb 15 '19 06:02 dmonllao

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.

  1. 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.

  2. 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.

  3. 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).

stronk7 avatar Sep 27 '19 08:09 stronk7

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

scara avatar Sep 27 '19 13:09 scara