 Thank you very much. This is a warning. You won't see many fancy slides. You will see code here. So anyone not interested in code or live stuff in the terminal should leave now. Last chance. Okay. I want to pass a challenge to you first. So what is the biggest issue issue for Moodle? That's a question. You just can meditate over it during the presentation. We will get back to that stuff at last in the finish. So who am I? I'm Karsten Ilsan living in Germany working mainly for clients in the Nordics. That means Norway, Sweden, Denmark. And I'm working with PHP since nearly the beginning. I don't know, PHP 4 or something, PHP 5. It was the time that we were talking PHP HTML before it got PHP. And with Moodle actively since 2011. The project I'm working on is a project of the Norwegian state supporting students in the math and language learning for migrants and or even Ukrainian childs that have moved to Norway. And besides that I'm a drummer. I'm a Viking reenactor. And I'm beer brewing. So to complete all the cliches. And I'm a jinkerer. I like to build things. Not even in code but in real life. I'm fixing my car myself and such things. So I like to have my hands dirty. And going into the terminal is the virtual way getting your hands dirty. So that's what's supposed to happen today. So what is I'm trying to do with Composer? Composer is already used in Moodle. But only for automated testing in the complete core development. And it's highly integrated into the ticket system we have and the tracking and so on. By side I'm not related to Moodle or to Composer. So I'm just a developer working since years and always stumbling a bit over issues here in my process that I am seeing on other vendors like Drupal for example. That's the other part I'm working mainly with. What we could do with Composer is automatically deploy a defined state of Moodle. So not just Moodle but Moodle with a defined set of plugins for example. And that is usually the case when you have many customers, the customer X want to have a Poodle Minilesson installed and customer Y is working with H5P and so on. And so you can describe this situation in Composer and Composer is taking care for you about anything that needs to be installed, moved or whatever. The cool thing about Composer is that it's able to solve very, very complex dependencies in this working process of passing code and plugins and everything in place so that you really have a running configuration. And I like to tinker with such things even because we can tinker with it notoriously. Today when we're working in a single project with Moodle, I'm not talking the cloud hosting stuff or big deployments or anything. I'm talking about one project because I'm a self-employed developer working since years and if I have the possibility to serve my customers on different sites with the same product, I would like to have a sort of automation or a standard I can move in and define those environments where I'm working with. And Composer in Moodle, this is just now happening by custom scripts developed by Moodle. So you have many opportunities to fix things in Moodle but you have to go in, you have to know the admin, CLI command you have to run, maybe you're writing a bash script or a make script or whatever just to automate that thing for you. And if we look at this here, when we want to update plugins actually, we have a running installation in Moodle, we have installed 20 plugins, everything is fine now, we get a mail with security issues for different stuff, so we go in and our admin backend look at the plugin states and we say okay, we have those five plugins that has to be updated. Then the first opportunity is we go in and do it live in the admin backend, we click on update and the server is handling everything for us. And that is a bad idea. Security wise, you have to leave writing rights to the server. And that means every upload that is happening into your source environment, into your directories where your code lives, you have to open all these directories so that the server can write code and store code where it belongs. But that means every user can do so because the user got the same rights as the web server in that case. So that means every upload that is happening in Moodle is a potential security risk if you go down handle it right. And so I as a developer and a notorious security nerd and GDPR fighter and whatever, don't want to have this whole on my server. So that's working fine if you're running 50 users inside your university in an internal network but as soon as you go out in the world and you have an open web server, you won't, you will not live long and prosper if you're doing it this way. So the other way around is that you check your list, then you have to remove manually the old plugin code, download the new plugin code, move it manually into the folders again and then you go and run the front end update and everything. So that's very simple task but you have to do it manually. You have to go in, copy, paste, download, delete everything. And as we all know, manual action is not fail safe. We can do it 500 times really cool and then we were on the Moodle party and the next morning we were doing it the wrong way. So, and then we have the issue. And that's actually worse if you're gonna really upgrading Moodle itself as a solely instance on a machine. You have to get rid of the old installation completely, copy the new Moodle stuff over and then you have to know which plugin did I install and copy every one of them over to the new installation. And it's up to you to define this configuration. You have to have a list or whatever where you, or you have to do a screen dump of your plugin list, what are the additional plugins I have and we're coming later to the point where the Moodle's storing all the plugins. So it's just a critical thing there, where they are storing the code. We are running to, I don't like that set of working and just deleting the complete code base and copying over the new version. So we run a slightly other way. We are patching our code base. We're just taking, maybe we are on Moodle 4.13 and the new 4.14 is coming out. I'm just doing, creating a patch from 1.4 to 1.45 and then I'm applying that patch to our code base. So I know it's exactly what we want. I'm hoping that everything is working fine in that case, but that's much faster and easier for me as a developer to be on track there. So I don't have to manage a list of plugins because they are untouched. They are left there. So Composer is there to help us solve all these problems. Composer is an application level dependency manager. If you look at Linux or whatever, if you take apt or Pacman on arch level, that's a dependency manager on the system level. So where I can define dependencies that the web server has or PHP has or whatever. And this application level, so we are going down to Moodle or Drupal or whatever and this one has the ability to clear up dependencies just in this realm. It's inspired by NPM and bundler from Ruby and it's even that time it came up where we had a lot of new languages coming up in the community like Ruby and Nude. It started by some guys from the symphony team in 2011 and we're currently in a 2.2 version and it's pretty fast and it's since then has become nearly the de facto standard for dependency management on project base. So that's Composer in a glimpse. And as I said, Moodle is already using it for the BI testing, working pretty fine, everything's cool despite of some things that is in our way to really implement that as a usable tool for us developers. So those QR codes are leading to Composer page on the front page, to my LinkedIn page and so on. So just if you want to. So when I'm talking dependencies, what I'm meaning here, you have a project that wants to have or that we have the first level of dependency. I want to have a plug in fixing a forum or I want to plug in fixing a newsletter tool for my project. That is first level dependency and those dependencies can have any dependency too. Both are building or using a library working as mailer, for example. And that can go further and further and further. And to make it more complex, you don't have those libraries, you have even versions. So the first library wants a mailer with a version higher than 1.3. The second library needs a mailer with version at least 1.4. And Composer can take all this stuff and create a configuration that's working. That's solving all these dependencies you have defined in your or is defined by the functionality you want to achieve with this configuration. So that's the magic of Composer. The workflow here is you have a Composer.json. That's a thing you will find everywhere if you start Composer. Composer.json is a configuration file for Composer itself, for the project, for plugins. You find it everywhere. And the cool thing is because it's called Composer.json, it won't interfere with anything else. So it's just Composer reading this stuff and that makes it very convenient to find all your configurations if you have a struggle with some configuration or whatever. Composer calculates a working package configuration for you and you can use it to download the required packages, put it in place where they belong. Then you can use Composer to check for updates if the package needs a security update, a major upgrade, a lower upgrade, whatever. And then what's cool is Composer has a plugin system itself. So you can extend this functionality and you can even fetch patches from forums or whatever. So you can define code repositories like GitHub or whatever, but you can even pull a zip file from a forum where you say, okay, that's an issue that hasn't gone in core yet or hasn't been fixed by the plugin maintainer. I'm just pulling the patch directly out of this forum post and putting it into my project just now, just to get it working. And as soon as the plugin maintainer is updating its code, Composer was like, okay, I have an issue here. So this version is not working anymore with the patch I put in before. But at least as long as this issue occurs and you rely on this patch from the forum, Composer knows about it, every update will include this single patch and that's a quite cool thing if you're living a bit on the brink and on the edge and want to stay secure with your system or with a new functionality that isn't quite mature yet or has some issues. And another thing that is some, which struggles me a bit if I'm working with the Moodless is we are still in a sort of spaghetti code way. We have many legacy plugins starting, if you're starting reading the code of a plugin, you make a journey back in time, 10 years. You're starting with index HTML and then you have a huge matrix with switch then or if then stuff is the formula canceled, okay, not then do this. And that's not the way it's supposed to happen today. We're working in a, we're living in a code, object oriented code world where we should have classes and such define, definements there. And this is Eve handled by Composer 2. Composer can generate outloaders for you. If you're importing a mailer, library, whatever, then Composer knows that and generates a file that you can include in all your stuff and then your app knows I have the mailer and it knows how to access this mailer. So it makes the life convenient for us developers too if this is implemented the right way. So now I'm trying to do this life. I hope the internet connection is stable. So we just go for it and now we will see where we're landing with this. And now this is the thing I was talking about when I warned you. We're really going into a live Composer session here. Maybe I should make it bigger. So, and I'm now taking first example how it's supposed to work. And I'm taking Drupal because I work much with Drupal too and there it's working pretty well. So I'm just going this way here. So I'm now in a folder called demo. It's completely empty, that one. There's nothing inside there. Drupal has a convenient method as it has a sort of a project template. Lying in the web. I just can relate on that one. And there we have some basic configuration inside that is make up a usable Drupal configuration. So I'm just importing that one. We will see here. I have done this before. So if we go through this command here, then you see I'm just calling Composer. I'm just calling the command create project. Then I'm relating to Drupal slash recommended project. Drupal test is the directory where all code shall be copied to. And I have chosen to take the approach of no install just now so that we only generate the configuration file. It won't fetch any information or data from the web. So I'm running that one. And now you see that's how Composer is working. It's just going to the repo fetching those recommended project files and storing them in the folder that I have defined before. So now I should have a Drupal test folder. And if I go inside there, you see a Composer Jason and a Composer lock file. Jason is defining what I want. Lock file is defining what have I done. So what is the state? Because we're going into the Jason file shortly and I'll show what's the difference between the Jason file and the configuration of the lock file. So let's have a look at that one. So this is Composer Jason file. As the name suggests, the format is Jason. So here you can see this is the basic configuration for a Drupal project. You define a repository here in this line. It's a Composer repository. It's Composer compatible. We will go on and define other types here soon in the next few minutes. This one is relating to packages.drupal.org, which is a server just providing Composer information about all the plugins or modules, how it's called in the Drupal world, is delivering. And we're talking, on the module scene, we have in Moodle, I think 2,000 plugins. Moodle, we're talking 25,000 modules. So that's really, really many, much stuff to keep track of. And here you see some core dependencies, Composer installers, Drupal core recommended. And you want a minimum stability of stable, for example. So this is how a kind complex Composer Jason file looks. We will have a much simpler version for our Moodle test. So here you're defining what you want to have. And if we go out here and take a look at the Composer lock file, then you see that everything we want to have gets a content hash so that you really know, okay, that's the version. Because if you look at the Composer Jason file, take that one, you can see so-called constraints. So I'm defining, or they are defining, they want to have the Composer slash installers library. And they want at least the version 2.0. It can be 2.1, 2.3, or 2.1.1, but it has to be 2.0. And the Composer lock file is defining which one do I have actually now. So when you're checking for updates, Composer is just jumping into the lock file, taking the hash, sending that to the Composer server and the Composer server is saying, okay, there's a new one. And then you can see that in the Composer update. So it's a quite convenient way to start a project. And as soon you're clear with your configuration here, you simply run Composer install. Or in this case, we have already installed, we're doing a Composer update. And I will put on the, this one is always helpful if you're running Linux Commons. It's a verbose mode, so you see everything is happening in the background. So now you will be flashed with, oh, damaged. Okay, let me take this one. Not double dash, just one. So loading, let's see. I'm not in the right directory. There we have it. So now you see, this one is checking everything on the removed server. And the connection is quite good, I see. It's caching it locally and hopefully downloading the stuff. As said, we're living on the brink here. If the net is going down, we won't go further and you can have a second coffee. There, okay. So let's see what we have here. We go right up. And you see, here you can see some messages that you would even see without the verbose mode. It's installing dependencies, libraries that Drupal wants to have, marking the versions in the log file. And after that, you should have a running Drupal version. So if we look into our directory here, we see, I'm just clearing up the screen. We have now a vendor directory and we have a VAP directory. In the VAP directory, we will have some Drupal stuff and in the vendor directory, we have all the dependencies sorted after their naming. So that's quite cool. I can pass a composer JSON file to anyone. That's just a bit of 80 kilobytes or whatever. And this person is able to install except the same configuration I have done on my machine. So that's how it's supposed to work with a composer. And we can even see, which shouldn't be the case now, we can run a composer outdated and maybe we just reduced that to the Drupal realm in this case. And then you see, okay, everything is up to date. Just checking for the plugins, everything. And that's the cool thing. That's an easy task and you don't have to move anything manually around in this case. So what do we want to do now? Let's see. What about a plugin? We have create project. We will see. I just have to import some help here. We should see. So there. If you want, do we have that one? So this, for example, I don't know, can you read that or is it too low on the screen? Otherwise I will just move up a bit. So if you want to add a plug or a module called in Drupal, you just define that requirement with the composer. So normally you don't have to go into the JSON file and add things manually. You just can use composer to add this. So in this case, I just want to have the Drupal slash admin toolbar. And I want to have it in the version 3.4.0. So just doing that one. And as you see, that one is, it's putting the information in the log file and the JSON file. It's downloading the files in the right directory. And we're done. That's it. That's how an installation should work. So, and if I'm now passing composer JSON and composer log file to my developer or my customer and they are running composer install, they will get exactly the same code base as I have. That's just five lines of code. And it's so convenient, really. If we now look into our Drupal directory structure here, then one thing that Drupal and Moodle have in common is they store their plugins or modules inside the core directory structure. It's just like Moodle has 500 different paths where you can store your plugins. Because Moodle's core architecture is built around this that it has to be somewhere in this folder. All activity has to live in the, or all activity plugins have to live in the mod directory and so on. And it's even going deeper. So all editors, you have ATO or TinyMCE or CK Editor, whatever, they are living in lib editors. And then you have their CK Editor. And then you have lib editors, ATO plugins, where you have other parts. So that's, how do you keep track of that? And Drupal has only two or three maps where they store all the stuff. That's modules, that's themes, and then they have an external stuff for libs. But the main stuff is stored in core. That's Drupal. Drupal only. You don't mess with that map. You can go in to look for something or whatever, but you don't do anything that. That's where Drupal's code live. And that makes it easy to upgrade. Because it's completely on the other scale. It's out of your responsibility to deal with this folder. You're only working in the sites and the themes folder if you want to, or modules. So that's a thing. And we have installed a module. And if you see here, we're just going into web modules. And it's, then they have a thing. You can do contrip modules that are modules lying in their repo. Or you can have custom modules that's local development. Only you have access to that. So they have modules, contrip modules, and custom modules. So this one should live in the contrip. And if I look there, we have admin toolbar for you there. Admin toolbar is the map where this code is living. So that's Composer. Composer has done a very good job for us just now. And now we want to see how handles Composer. We take another shot here on Composer outdated command. Just for your information, these are the commands you can do with Composer. Quite convenient. Just hack it in. And every one of that has a detailed helping page. So it's convenient to work with that one. So if I go in, Composer update, Drupal slash store. Checking for updates. And then we see, okay, everything is fine again. So we have the last one. That's cool. Oh, wait, we can do another one here. I'm just, as said, this will be a live coding session. If I have a good idea, I will do it. If I go in and I just work on my Composer JSON file, let's see if that is working. And that's the Composer JSON file we saw before. Now we have required the Admin toolbar and it's added to the Composer JSON file automatically by Composer. And as you see here, we don't have any constraint. We have, we want to have the version 3.4.0. And if I want to check if there are, or I have defined a fixed version, but I want to get in updates available updates, I have to define a constraint that makes it possible that you have anything younger than 3.4, newer than 3.4. This is defining 3.4 dot, that was it. So now we're just doing, let's see here, we're doing a requirement, let's see, 3.4. If I'm adding that, I'm going to add one here. And then you see Composer is, I've changed the constraint to a more flexible style. And as soon as I do that, Composer is checking, okay, there is a newer version currently. So it's just fetching the code, installing it done. So that's how you handle updates if you do it manually. Despite anything I'm doing here, the complete session is considered a question, a Q and A. So if you have a question, just raise your hand and throw it in. So I like dialogues. Let's see what we have here. That was something that was Composer Jason, admin toolbar. That's cool. Okay, now I run Composer removed Drupal admin toolbar. And Composer is just removing the code. So I can get rid of old stuff too. Composer is just dealing with it. So we have any option running here in the command line. And normally it's just one row, one command short defined. And that makes it easy to have them in automatic deployments, in setting up environments for automated testing. And that is the core strength of Composer. It's so simple that you can use it in your everyday work. And it's so easy and simple that it's quite fail-safe to use it in automated scenarios. And that's quite a bummer for me or makes my life as a developer very easy or easier. I don't know if developing for Moodle is considered easy ever. Or yeah. Go on. You have to be a higher wall. Yes, yes. You can actually downgrade. There are two ways. Either you leave it to Composer. Then it's sometimes complaining about not or good dependencies. The easy way to downgrade is really just get rid of the plug-in and install it with another constraint. And then Composer will develop or calculate a new dependency chain and everything. And caching everything up. So it is possible to downgrade. But make sure if you're running Drupal or Moodle that you do that before you update the database. Because we always in Drupal it's nearly the same as in Moodle. We have a two-stage set of installation and upgrading. And that means we're upgrading the code and then we have to go into the front and run the front-end script so that the database changes or whatever has taken place is taking place. And if you have done that, it's quite hard to get back to another version. So always back up before you do that. Better, better always back up. Yes, there? I see that you installed some plug-in but you don't figure what we deployed. So how it's done in Composer. I want to start to do it in Moodle and tell them that all the plug-in of Moodle, this plug-in will be in Moodle directory. So how you can set different directory for each package that you installed. Do you mean the directories where it's installed in? Yeah, you do Composer require admin-toolbar. Yeah, okay. How I find this one, the name, you mean? How we know to do it on web modules country? No, no, no. That's the cool thing about Composer. I'm not in the web location here. I'm in the root directory. And I'm in the same directory where the Composer JSON live. And if I'm running Composer require this plug-in or this module, Composer knows exactly where it has to store this code. Where it's configured. Okay, that's the easy part. I show you directly and that's why I want to dialogue. Exactly, cool. So if I run this one, I'm just checking the web modules country. Wait. I de-installed it. I have to install it again, sorry. There. So I've just in a timeframe of three minutes, I've installed, de-installed, installed again without any issues. So now I'm showing you where this is defined. We have, on the first brink, we have this one. We look at this one. If we go into the Composer JSON file that Drupal is providing us, then you see this one here. Installer pass. This one is building on the Composer plug-in Composer installers. And Composer installers is a plug-in for Composer that is taking many frameworks like WordPress, Drupal, even Drupal. I will show that later on. And tries to find out where should I store which sort of plug-in. And as you can see here, we have some stuff is Drupal core. It's typed Drupal core. And it has to be stored in web core. Typed Drupal library should live in web library. And here you have that one that we have run. That stuff we are running with is a Drupal module and it has to live in that module's contract. Exactly. Yeah. And now this is a definition where Drupal wants the code to live. And now we look at the module itself. Sir, we're just going, this, we're going in web, modules, contract, admin, toolbar, Composer JSON. And what you see here in the third row, you have type Drupal module. And that one was defined in the Drupal world. And that's exactly where Composer has its strength. You can nearly configure everything in that one. And you can add your custom plug-in and you can add custom script that should be run after the installation before the installation, whatever. So you can really create a Composer version for yourself running just for your local developed one at home or in the office. But it's much, much better if an environment or a framework, a project like Moodle defines this for you. Just like Drupal do. They have done a huge job. They had the same issue we are sitting in just now in Moodle had Drupal with the version 7. Version 7 was the last Drupal session with a fucking amount of spaghetti code and a very bad architecture for us developers. And they changed over to Drupal 8. That was a major, huge rewrite of the complete system building everything around the stuff that we can work object-orientated. We have namespaces. We have outloading. We have Composer integration and everything. And that makes the life so much easier. And that really created a Drupal version that I wouldn't call it CMS anymore. It's not a content management system. It's really a development framework. You can do anything with that one, with that stuff. And that's quite cool. But it was a huge effort they had to take to get to that position. And that's why I'm standing here. I like how they handle the things with Composer. And I would like to have the same easiness, the same security, the same convenience in developing for Moodle with Composer. But that takes us to the point where we have to start planning that because actually Moodle is quite complex in its structure. And if we want to reach that goal anywhere soon in the future, we have to start actually now. And it will take a while before we are there where Drupal is. But at least we should try. Because I think that's the way to go. Okay. Any other questions? Yeah, they're all there. So as I understand, this is the Composer JSON file of a plugin, right? Not of your project, the one that you have opened now. The Composer JSON file is a part of... But this is the Composer JSON file of a plugin. Right. Yes. It defines what type the plugin is, what's the title of the plugin. Yes. And also the version number of the plugin probably. No. No. But the requirements, how is this plugin requiring some other? In this case, I've just scrolled through it, this plugin is not defining any other dependencies just now. But it could. It could define dependencies. And we could have five plugins defining the same dependency. And Composer will figure out which version of this dependency is working with all five plugins, even if they are demanding different versions. And if you have two plugins demanding version that are not compatible, Composer will tell you that so that you can take measures, actions, whatever is needed. Either choose one of those or update one of the plugins or whatever. But Composer is quite cool in spitting out hints where the issue can lie. And that's helpful for us developers, too. And it has some handy tools built in. If we, for example, just ask Composer why Drupal admin toolbar? Then it's just saying, okay, it's a pod project that requires this one. If I'm going to a dependency of a dependency, and I ask on my other slide here, if I would ask Composer why Mailer, it would list plugin forum and plugin newsletter as those who are demanding this dependency. So it's giving me even tools to analyze my setup and getting into the issues that may occur during running this stuff. So it's a quite cool tool to build a good environment. It's quite a cool tool to keep it safe and updated the easy way. And it's a cool tool to debug your system if you're stumbling over some issues there. So any other questions just now or I'm just continuing. I have enough stuff. I don't know where we are at the time. What is it? 13. I guess I had a bit of a question, sorry. Obviously Moodle is not at all organized like this, as you said. I'm sort of kind of, I'm very much used to the idea of you create, you know, we work with Git, we create repos, we commit the plugins to a customer's repo, we then deploy, use Git to deploy that to a customer's site. If we were going down the Composer route, would we basically say instead of doing that, we'd go to the server and we'd run Composer on the server and apply it? So how do you get from using Composer to get all the plugins together to actually deploying it onto a customer's site? I know where you're going. That was a huge discussion when Composer came up. And it was always a discussion with the other dependency managers as well. And I know people or developers that are really just shipping the Composer JSON and Composer log files and say, okay, even in the deployment, they're deploying this file and then they're going to the production server and saying Composer update. And they are, I think it's, my approach is a more conservative thing because that is, or the permission running this one is that the Composer package server is online. You have connection to that one because you have to pull a new code. Composer on the server has to run. Composer is in that case an additional part of software that can provoke issues in the production system, in my case. So I'm always taking the conservative way of running this. I'm running this locally in my development environment. And if you go to Drupal and look at this standard Git ignore file, for example, let's see if it's in here. Not there. Let me see here. Yes, no, it's not in here just now. Okay, but what do you mean? Yeah, maybe you're right. So let's see. Wendor and the, the Git ignore file is living in the Drupal vendor. But that wouldn't, maybe okay. We see. Core recommended. Not really there. No, no. Okay, but what I want to say is usually folks are running Composer and then they have a Git ignore file ignoring the vendor directory. The vendor directory is just hoarding every external plugin that is not directly related to Drupal. So maybe the mailer or whatever. That are PHP libraries that are working with any project or any integration would work. They are not Drupal related. We could even use them in Moodle if we want to. And all this stuff is hoarded in the vendor directory. And normally projects just ignore the vendor directory, but that means you have to go to the server and run a Composer install update to fill up this vendor directory. And that's something I'm not doing because it's dependent on a running packages server delivering the code and anything. I'm committing my code including the vendor directory to the customers repo. And that's my reference for deployment. But if I have, I want to start a new project, for example. I can have my own Composer configuration where I start from scratch. So that's just quite usual way for me as a freelance developer that I have some templates I start with. I have, I don't know, I have six or seven running Drupal instances that are built around Composer for seven different clients. And they're running for years now. I just can, that's five minutes to upgrade the system with Composer locally and then deploying the code over. But it's huge. It's helpful for me. And I'm not talking any complex test chain or whatever integration with year or whatever. That would get much easier if you have this tool relatedly and good implemented into Google as a project. Yes. So let's see if we can, 15, 17, how long do I have? 22 minutes. Okay. Let's see where we can get in that time. 12 minutes. Okay. I had a lot more on the list. So okay. Let's just jump in. What Composer can do or is doing in the back end is we have a local Composer JSON. That one goes to packages work in the Drupal case here. Packages is driven by the Composer developers. It's a repository where everyone in the open source community can push their packages. And then you have a very nice matrix there. Let's see if we open that one just. So this is a repo about 1,000, 100,000 libraries available for the PHP community. Drupal is running an own instance of this one. And that was my plan to get into that one. But okay. You can't get what you want. So because Composer has a running server or a working server that you can implement on your own. So there's nothing in the way that Moodle shouldn't as organization provide an own package server just like Drupal does. So we could have packages.Moodle.org serving just like this and be a hub for us developers fetching our plugins that we need. So this is packages delivering all the stuff we need. And packages has a method in syncing with GitHub or other Git repositories like Bitbucket or GitLab, you name it. Composer has a huge list of supported sources you can use. And packages let you implement some GitHub actions. So if you're updating your package on GitHub, GitHub is signaling that to packages. And packages is pulling in a new version. And the versions that packages is taking care of are defined by GitHub or Git tags. If you define your tags you see, okay, version 1.0, 1.1, 1.3. packages knows about that and as soon as you do the update request it will just fetch those tags. So we have a quite simple setup. So create a GitHub repo, define your versions with tags and then push this to packages and you're good to go. You have a plugin that is downloadable by Composer. It's cost less, effort less free. If you want some more extra features or closed source stuff you can buy that from packages. They have a private repo offer but you don't have to. We don't have to. 2,000 plugins are free. We are open source. Either we use this architecture or we build it ourselves and everything is lying there. It's just waiting to go. So that was what I just said here. So what are the hurdles for Moodle to implement that one? The first thing, as you see everything I was doing here was using so-called semantic versioning. That means we have three digits of versioning. 1.2.3. Three are minor patches, two are minor updates and the first grade is major upgrades. We even struggle to have this at Moodle level itself. It's my opinion now. I'm ranting a bit. If we are running from 3.1 or 4.1 to 4.2 we're just doing the same as if we were running from 3.9 to 4.1. So even if the jump from 3 to 4 should be considered a major upgrade, the process is exactly the same. Why? I never got that. Why the steps from 3.1 to 3.2 is the same as if I go from 3.9 to 4.1. The first two steps, the first two charts are considered major upgrades. If you're in the logic, for me it's a no-go. We should have a major upgrade which just now every minor upgrade should be a major upgrade. That's why we have Drupal now in version 10 since 4 years. Drupal 7 or since 10 years. Before that we really had 7, 8, 7, 9, 7, 10, 7, 13 and so on. We have them but that are minor upgrades that are running with the same major code base. We don't have any deprecated codes or deprecated libraries or whatever. APIs are the same. That's something that handles the minor. And major upgrades where you deploy code where some things break, get incompatible, are old, whatever. So Moodle itself should consider a refinement of their versioning system and if we go into the plugins we have the same system. Actually we are just defining this version PHP file and we have usually a date. This plugin is from 2023, 08, 21 and then maybe a two-digit version number for the day because every developer is committing five times a day. One plugin before it's running really good. That's why we have those two digits. The good ones take five. The good ones take six, seven. Just a guess. But that's an issue we have. The directory structure which I'm sorry I couldn't get into that one but there is a slight start support in Composer for Moodle. So we can have a Moodle installation. We just have to get rid of the actual Composer JSON file we have in Moodle and then we can install plugins. It's working. But there with this versioning based on date it's very difficult to define a constraint. So I would have to say okay give me every plugin. This plugin should only work from I don't know the 21st of July 1999 and younger. So that's not really an option. So we should push our plugin developers just to include the Composer JSON file. It's effortless. It's four rows of defining dependencies, defining a version and everything. And that would make 2,000 plugins compatible to use with Composer. And we have quite good documentation inside the Moodle community. How a plugin is supposed to look, how a plugin is supposed to, we have good code checks in our tracker and our everything and that should be part of that. So just consider pushing a Composer JSON file and taking it correctly in your GitHub repository and you're done. Then you have the first step to a running Composer environment. Yes, okay. So we are able to provide custom repos and sources in Composer. Composer has plugins so we can get around some issues we have with Moodle. And if we want to run an own package server, there are two or three out there that are already cloning the Moodle plugin repository and building that one but they are not working very well because of those constraints, missing versions and so on. So that's something we have. This would be a project just now if we had two hours. So what I wish from Moodle is first get rid of the Composer JSON file we have now in the repo or change the type from project to Moodle core. If we do that, we are able to handle this core code better. So that would make things easier. Just now it's only possible to get rid of the included Composer JSON and writing it from sketch. Then we would, it would be cool to have a central Git repo with all plugins. Correctly compels a JSON and every one of them. Then we should stand on a semantic versioning in plugins and in Moodle core itself and it would be cool in the long end to have an own package server for Moodle. So questions, we had questions. Any more? Not really. I think it was a long three days and this is the last stuff I think, okay, you will sleep very well tonight. But yeah, was there anything? Yeah, there's a question. Are you aware of a tool and a platform maybe also? It's a package repository for Moodle plugins automatically updated from the Moodle plugins directory. Yes. I think it's called Moodle gist, something like this. Like package gist, Moodle gist. Yeah, okay. I know that. I said that we have two or three, but I would like to have that from the Moodle core team just to ensure the code quality. And even here we all have to be sure that the chain where we are fetching our stuff from is trusted. And I would like to have Moodle core team. But this grows from the API of Moodle packages. Yeah, I know, exactly. So there's nothing that it only applies some transformation to the, and it has version, like version dependencies, it has all the latest versions that are quality control on the package directory of Moodle. So it's only a layer of bringing this to the composer. Exactly. And you can, you can find... What's missing there? Yes. Maybe any other plugins that are not published on the, on Moodle packages, then it's difficult to get into your composer. And then Moodle itself, as you're saying, it's not composer friendly on its own having this composer JSON file that it's mostly for development and it's not defining its packets as a composer package. Yes. Yeah, I know. And also the Moodle installer that it's part of the installer, it's not compatible with some new versions of plugins. Tiny plugins, for example, they're not there. The payment gate, which I think they're not there. So, yeah. Because not many people are using it. And the more this, I agree with you, would be become a practice. Yes, this can definitely improve a lot both the development, the deployment and upgrades. Yeah. All kinds of stuff. Yeah, exactly. I'm with you. And that's, that's exactly the point. We, we come to you shortly. Satis, as a, as a standalone packages server, can even work for you as a provider of those solutions. If I would have five or six installations of that case I'm running just now, I would surely run an own packages servers with trusted plugins I am supposed to use. And then I just would set that dependency in my own projects, go to Carstan packages and get the stuff there. And I'm sure which code gets deployed. So that's one thing. And there is another question. Yes. Actually too. Okay. But you have to hurry up. Do you have a tracker in Moodle about these changes that you used? No, not yet. Not yet. I, there are some composer requests lying around in, I don't know, 2019 or whatever. But I think, I'm a first time Moodler here on, on this conference. So I should have been in the track yesterday that happened here and have a five minute presentation about this, because it's a proposal. We, we should have a group on Moodle taking care of this one. So, but before you all leave, I had a challenge. What the biggest issue Moodle has now. And I can't leave without that one because my wife would kill me if I don't take the opportunity to talk to, I don't know, 50 people. And the biggest challenge we have is the climate crisis. Lifelong learning means you have to live and have a place to live. And if we don't fix that, we won't have pupil students, whatever. So remember that when you book your flight ticket. I took a 20 hour train ride from Germany. So I raised my radius from under 1000 kilometers to 1500 kilometers is possible by train. It's hard. And you have to book a good room at your tent to sleep just now. But that's the way to go. Without that, we can just scrap Moodle. I say that. So, and the time frame we have to act is quite short. So keep that in mind when you leave. Thank you for attending this one. And I wish you a very good journey home. Stay safe and keep calm.