Creating your own Briks or modifying existing ones

Starting from Metabrik 1.24, you have an easy way to create and use your own Briks. You can even modify existing ones and they will have precedence over the system ones. Let’s dig into that awesome features in this post.

Update to latest version

As always, you should be running the latest version. To update, it is as simple as running in the Shell:

use brik::tool
run brik::tool update

You should even put “use brik::tool” in your $HOME .metabrik_rc file so it is loaded at every start. Do the same for brik::search Brik, you will see how useful it can be.

After the update, you can either restart Metabrik or use the “reuse” Command:


You should also add an alias for your prefered editor. Starting from Metabrik 1.23 version, the default is to capture external programs output, it won’t really work with editors like vi. In the end, you should have some lines like below in your .metabrik_rc file:

use brik::tool
use brik::search
alias vi "run shell::command system vi"
alias search "run brik::search"

Creating a skeleton of a new Brik

The brik::tool Brik has many useful Commands. One is used to create a skeleton of a new Brik for you. Try help to see others:

help brik::tool
[+] set brik::tool datadir <datadir>
[+] set brik::tool repository <Repository>
[+] run brik::tool clone <Brik> [ <Repository> ]
[+] run brik::tool create_brik <Brik> [ <Repository> ]
[+] run brik::tool create_tool <> [ <Repository> ]
[+] run brik::tool get_brik_hierarchy <Brik>
[+] run brik::tool get_brik_hierarchy_recursive <Brik>
[+] run brik::tool get_brik_module_file <Brik> [ <directory_list> ]
[+] run brik::tool get_need_packages [ <Brik> ]
[+] run brik::tool get_need_packages_recursive <Brik>
[+] run brik::tool get_require_briks [ <Brik> ]
[+] run brik::tool get_require_briks_recursive [ <Brik> ]
[+] run brik::tool get_require_modules [ <Brik> ]
[+] run brik::tool get_require_modules_recursive <Brik>
[+] run brik::tool install <Brik>
[+] run brik::tool install_all_need_packages
[+] run brik::tool install_all_require_modules
[+] run brik::tool install_needed_packages <Brik>
[+] run brik::tool install_required_modules <Brik>
[+] run brik::tool test_repository
[+] run brik::tool update
[+] run brik::tool update_core
[+] run brik::tool update_repository
[+] run brik::tool view_brik_source <Brik>

Let’s create our first Brik named my::first and start editing it like:

run brik::tool create_brik my::first
vi $RUN

The first thing you may notice is that the create_brik Command has created a new .pm file and the associated full hierarchy to access the file. We used a run Command, so $RUN Variable is set and we can use it to directly edit the new Brik.

We created an alias for the vi external command, so it worked like a charm here. If you had an error, please go back and read on how to add the corresponding alias in your .metabrik_rc file 🙂

We will not dive into how to actually write the code for a working Brik here. You have many examples already online on the trac server. But creating the path and the file is actually not enough to be able to use your Brik yet.

Another useful Command is view_brik_source. You can easily see source code for any Brik by using this Command. Example:

run brik::tool view_source_code core::context

But well, core::context Brik contains all the magic behind Metabrik and is by far the most difficult to read for non-Perl programmers (and maybe even Perl ones?).

Making the Brik useable

The file is created and you want to use it. If you do it now, you will have an error. Well, in fact, you will be able to load it but the system cannot find it automatically yet. So you have to update your running context like:

run core::context update_available

This Command will go through all directories containing potential Briks to make them accessible to other Briks. You can then search for yours by Tag, for instance:

search tag my
[+] Used:
[+] Not used:
[+]    my::first [first, my, unstable, used]

And finally use it and ask for help on how to use it:

use my::first
help my::first
[+] set my::first datadir  
[+] run my::first install

As you can see, we can search for existing Briks by Tag. A Tag is created based on the Brik name and other properties like is it used or not. You can manually add Tags to your Briks by editing the Tag Property.

And what about modifying an existing Brik?

Ah yes. First thing is to find where the Brik you want to modify is stored on your system. It is usually somewhere in /usr. In our example, we want to modify system::os Brik to add support for a new operating system:

find /usr -name
my $os = $RUN->[0]
get core::global repository
my $local = $GET

We found our Brik and saved it on a Variable. To copy it to the correct Repository, we have to create the subdirectories in the good way. The local Repository is the good place to do that, so we fetch it by using the core::global Brik and save its path to $local Variable. We did also saved the path to original Brik into the $os Variable.

The name of the directory has to follow the Brik name, and be put in a parent lib/Metabrik directory. So, the Brik named system::os will end up in the lib/Metabrik/System directory. You will have to mix Perl code with Metabrik Commands to do so. Then, copy the file and change its permission:

my $dir = local.'/lib/Metabrik/System'   # Perl code
mkdir -p $dir  # A Metabrik Command, called for you with "run shell::command capture"
cp $os $dir  # Also A Metabrik Command, called for you with "run shell::command capture"
my $file = "$dir/"  # Perl code
chmod 644 $file  # And a last Metabrik Command.
run core::context update_available

EDIT: There is now a Command to clone an existing Brik, so you may skip all these steps. Simply call clone Command like the following snippet. The new file will be created and you can start editing it:

run brik::tool clone system::os
vi $RUN

You can now modify the code of this Brik. When you want to test it, just use the reuse Command:


That’s all for today, happy coding 🙂