 So writing of easy config files is important when working with EasyBuild because for every software installation we do, through EasyBuild, we need a corresponding easy config file. So that's quite important. But first, very briefly, easy config files and easy blocks. When you have very complex software packages that have a complex installation procedure, we may have to implement an easy block instead. So sometimes we can get away with using a generic easy block, which knows about how to install a Python package, for example, or do a configure make installation and so on. But for some software, this may not be enough. Imagine openfoam, people who have installed openfoam from source can imagine that any generic easy block that is able to install different software packages will not be sufficient for installing openfoam. So that's why we have a software-specific easy block for openfoam. Now the line between easy config files and easy blocks is not very crisp, let's say. So you may get away with very creatively using a generic easy block to get an installation done by adding lots of information to the easy config file. And that may be okay. But it depends on how complex the installation procedure is and also how much information you need to include in the easy config file. So here I've added a couple of reasons where when you should consider implementing a software-specific easy block rather than using a generic easy block together with a fat easy config file or one that includes a lot of information. That could be some easy config parameters that are very sensitive. So they need to be set to different values for different tool chains, for example. So you have to get that right in each easy config file and it may be better to move that logic into an easy block and get it done automatically. We may need to run interactive commands, so that's not going to work well through a generic easy block that doesn't know about them. We may need to pass configure options that are different for different dependencies. And we may want that to get done automatically, which a generic easy block would typically not do and so on. So there's a whole bunch of reasons where you're sort of crossing the line beyond generic easy blocks and going towards a software-specific easy block. We will not cover software-specific easy blocks in this tutorial. It takes us a bit too far. But there's an example that is given in the EasyBuild documentation. And there have been presentations about this before. So you can definitely find those on the EasyBuild YouTube channel. What we will do here is try to quickly come up with an easy config file for an example software package. And I guess we will leave the exercise in this part to do on your own time. So I'll just cover the example here in the demo. So there's a couple of settings or easy config parameters that always have to be there in an easy config file that includes the name software version, the metadata that is provided through the home page and description parameters, and the compiler tool chain that should be used for installing the software. So this gives an example of setting the name and the version. So this is nothing too surprising. I guess home page and description is similar. Just Python strings, really, where a description can also be multilined. So in that case, we can use a triple quoting that Python supports to make it a multilined value. For the tool chain, we have one special tool chain, which is the system tool chain. So this is a constant that the EasyBuild framework knows about. Before we specify the name and the software, the name and the version of the tool chain through a Python dictionary like this. So these are the only mandatory parameters. There's a whole bunch supported in addition. So you can get a long list of supported easy config parameters using the EB-A command. We'll cover some of them here. So sources, patches, and checksums. You see these popping up often in easy config files. They're actually not mandatory, not even sources is mandatory, because you can write easy config files that are just a bundle of other modules of other installations without actually having any additional software being installed. So that's why sources is not mandatory from a technical point of view. It is very, very common though to use it. Usually for sources, you have one or more source URLs where the source files can be downloaded from. You may have patch files that EasyBuild knows about how to apply them after unpacking these sources. And usually we provide SHA256 checksums for both source files and patch files. So EasyBuild will verify that the checksum of this file matches what is specified here. That's mostly to protect against corrupt download files or downloaded files. It's also up to some level a security mechanism to make sure you're not installing something that you don't want to install. Same thing for patch files, it's just a simple protection mechanism. For source files, you will not often see a hard-coded version like this, like we show here. You will usually see the use of this template version. So this basically is filled in by EasyBuild based on the value of the version, easy config parameters. That makes it a bit more easy to reuse this easy config file for other versions of the software. The easy block parameter is also specified commonly, but usually only when using a generic EasyBlock. So you can set EasyBlock equals to configure make or to Python package, for example, so the name of a generic EasyBlock. If it's not specified, EasyBuild will try to automatically find an easy block for the software based on the name of the software. So for example, for OpenFoam, you will not see an EasyBlock equals line in the OpenFoam easy configs because EasyBuild knows there's software-specific EasyBlock for OpenFoam, so it will just go ahead and use that. You don't have to specify it. For generic EasyBlocks, it's usually there, and some, a couple of commonly used ones, configure make for running configure and make and make install, or cmake make for doing the same, but with configure replaced by the cmake command. We have one for Python packages, which can do Python setup by install or pip install, and we have a Python bundle, which is basically a specific Python version of the more generic bundle, generic EasyBlock, which just glues multiple things together. There's a list of generic EasyBlocks in the documentation. You can also get them from the EasyBuild command line. You can also get them from the EasyBlock command line, and some of these EasyBlocks also have additional custom EasyConfig parameters, which you can see by using the eb-a command, which lists all the EasyConfig parameters, and adding an additional option to specify the name of an EasyBlock or generic EasyBlock that will add an extra section to the output that looks like this. These are the EasyBlock-specific EasyConfig parameters. For example, for configure make, we can change the configure command to something else. By default, it does dot slash configure, but if we need to, we can change this to something else. Of course, dependencies are commonly specified as well in an EasyConfig file. Let me just skip to the example that looks something like this. We discriminate between built-only dependencies and runtime dependencies, which we just call dependencies. Built dependencies will be loaded while installing a software package, but there will not be a corresponding load command in the generated module file. In this case, CMake will be there when installing the software. It will not be loaded when the generated module for the software is being loaded. Of course, Python here, HDR5 and SciPy Bundle will be loaded when this particular software package gets loaded. There's a whole bunch of additional details for specifying dependencies, so there's some options here that are not covered in the example, but are covered in detail in the EasyBuild documentation. One thing you will sometimes see popping up here is this additional template, the PyVerse template. This is just a way to avoid that we hard-code the Python version here and here as well. EasyBuild will just inject this value into here. If you want to copy this easy config file and change the Python version, you only have to do it in one place and this will follow automatically. That's the key idea about using these templates. The version suffix is a type of label that you can add to the software installation to indicate that it's a custom installation, specifically configured installation with maybe some bells and whistles that are not enabled by default, or it can be used like we've seen for subread, for example, to tag a particular Python version. Because we still have Python 2 and Python 3 that are somewhat relevant, so some scientific software still needs Python 2, so you may have models for both available, but you cannot combine them. That's why we tag these modules with the Python version through the version suffix. Easy config parameter. You can easily customize the configure build and install commands and also test commands through these easy config parameters. For example, pre-config opts is a string that EasyBuild will add before the configure command. While config opts goes after the configure command, so you have both before and after. And you have the same, not only for the configure step, but also for the build step, the test step and the install step. And these are listed. These easy config parameters are listed here, so the names are what you would expect. And the example here, we're telling EasyBuild to add this configure option to the configure command. We're telling it to run this command before the build command, so pre-build opts. And here, we're using a double M% to glue this command together with the actual build command. So remember, this is just a string that EasyBuild adds in front of the build command. It doesn't interpret this in any way. That's why we need the double M% to glue things together. And we pass the prefix equals option to install command, and in this case, we use another template value, which is the location of the software installation. So this will be completed by EasyBuild with the actual location where the software would be installed. This is explained here in detail as well. Then sanity check step. As you've seen, checks for particular files and directories or maybe runs simple sanity check commands as well during the installation to do some kind of validation. You can specify the paths through the sanity check paths, easy config parameter. So these are just links of files, lists of files to check for, and lists of non-empty directories to check for. And you can also define a list of one or more commands that should run within a zero exit code to make sure the installation is somewhat functional. These should be quick commands. The model class is usually defined as well, but that's a detail. We won't cover that here. So this is all to write easy config files from scratch, basically, starting with an empty file. Sometimes you just want to change something very simple in an existing easy config file, and then it's a bit annoying that you have to copy the existing easy config file, maybe even rename it, go in there, edit it, make changes. That's why we have these try options. There's multiple try options. The most commonly used ones are try software version, where you just tell easy build, okay, take this easy config file for version one, two, three of the example, and change the version to one, two, four, and try doing the installation, see what happens. Similarly for the tool chain, you can do a try tool chain to map or to change the installation without actually copying and editing the easy config file. So what easy build will do, it will take this easy config file, generate a new one, and then try to do the installation using the generated easy config file. And you will get the actual easy config file as a copied into the installation directory if the installation worked, or you'll have it somewhere in a temporary directory that you can grab it if you want to. And finally, another useful option here is copy EC, where you can easily copy easy config files to another one, a new file that you can start editing afterwards. So this is useful because then you don't have to first locate the full part to this easy config file before you can copy it. You can just ask easy build to copy it, since easy build knows how to locate the file. There's an extensive example here. So we actually have three example software packages prepared for this tutorial. We have the EB tutorial 100, which is something that we're going to see make. Then we have a one-one version as well of the same package, which is for the exercises. And we have a Python wrapper around this, which you can also do as an exercise. I will leave them here as an exercise because we're going over time quite a bit. So if you have any questions on the example or on the exercises, please raise them in the Slack channel, either today or in the coming days whenever it suits you, if something isn't clear here. But we'll largely skip those for the tutorial now. So unless there are questions on this specifically, I think we can move on to Alan and Maxime talking about how easy build is used in Ulich and at Compute Canada.