DEV Community: Alejandro Baez

Getting Started Using Nix Flakes As An Elixir Development Environment

Alejandro Baez — Sun, 09 Jan 2022 18:12:28 +0000

Never is a project started from 'just' the init. You have to take care of packages you use, CI tools for builds you make, database hookups, development tooling, and countless other parts. All of this takes time. With nix flakes, you may be able to start with all the main components you need immediately. Giving way to actually developing that app you been itching to build, without the days/weeks adventure getting everything you need just right.

Now it doesn't mean that immediately reading this starter guide, you will have everything under the sun set up with Nix Flakes for your development need. But at least, you won't have to worry about setting up asdf, your weird hacks you need for your machine and the other tiny little things to get elixir started with elixir-ls.

Background

A little background. Nix, for the uninitiated, is a purely functional language for package management. What makes Nix interesting is you can use the purely functional aspect to build out artifacts which are entirely idempotent. Meaning, no matter how many times you run the nix expressions you have, the end result will always be the same regardless of external state of a machine. Its build structure as a package manager has evolved the language to build out guaranteed result for all sorts of software. Yet, Nix itself isn't exactly easy to learn. Due in part to the ambitions of the project and difficulties, which arose from those ambitions, complexities crept in. Nix Flakes is an answer to some of these complexities and more.

With Nix Flakes, you have the ability to have a very well defined package for a project. Written and using Nix in a way that takes all the learning from its years. Making it easier to define what you want from nix; the build result for a package.

Getting flakes enabled

So how do you get started with Nix Flakes? The first part that you should probably have is nix already installed and some familiarity with the nix language. Run through the guide to your platform needs.

Next is the settings to use nix with flakes. Since flakes is still in development (but relatively stable), you do need to enable the feature on nix. You can do so by enabling the experimental features of both nix-command and flakes through the nix.conf file.

# make nix config path if not existent
mkdir ~/.config/nix/ -p
# add the settings to the file on config path
echo "experimental-features = nix-command flakes" | tee ~/.config/nix/nix.conf -a

Once the settings are applied, you should be able to validate by running show-config

nix show-config | grep experimental

If all is successful, you should see an output for the same experimental features you wrote on the nix.conf file.

The `flake.nix` file

So now to get to use nix flake comes the heart of the project, the flake.nix file. The file itself needs three defined keys on the set, description, inputs, and outputs. Each one of them plays a different role in how to define your package you want to build.

`description` key

The description key is a one liner description of what the flake project is. Helps in giving what the flake is for quick review after you have a few hundred of these built out...

# flake.nix, ignoring input and output
{
  description = "A description of some kind";
}

`inputs` key

The inputs is how you can import external sources of other flakes into the flake project you have. In other words, any project you may need or tools required to get started, this is where you will define their source. Example below is using the standard nixpkgs and a tool called flake-utils, which provides a set of functions to make flake nix packages simpler to set up without external dependencies.

# flake.nix, ignoring description and output
{
  inputs = {
    # using unstable branch for the latest packages of nixpkgs
    nixpkgs = { url = "github:NixOS/nixpkgs/nixpkgs-unstable"; }; 
    flake-utils = { url = "github:numtide/flake-utils"; };
  };
}

`outputs` key

The outputs is where the bulk of your logic for what you will build with flakes. It has quite a numerous of options, but in this use case, we only care of the devShell key, which is what will be used to populate the development environment. While the following may all look like a lot for the output, it's also everything that would be needed for either building out a nix flake package or use for a development environment:

# flake.nix, ignoreing description and input
{
  outputs = { self, nixpkgs, flake-utils }:
   flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; };

        elixir = pkgs.beam.packages.erlang.elixir;
        elixir-ls = pkgs.beam.packages.erlang.elixir_ls;
        locales = pkgs.glibcLocales;
      in
      {
        devShell = pkgs.mkShell {
          buildInputs = [
            elixir
            locales
          ]
        }
      });
}

The output key is actually a function which takes the inputs defined on inputs. Hence the set { self, nixpkgs, flake-utils }. All the inputs on the function were defined on the input with self being the flake.nix file itself. The next portion is using a simple but powerful flake-utils function called eachDefaultSystem. What the function provides is actually build the development environment for all available platforms currently available for nix as a default. You can see the list by running nix flake show (after the file is fully written) and you will be provided an output like the following:

└───devShell
    ├───aarch64-darwin: development environment 'nix-shell'
    ├───aarch64-linux: development environment 'nix-shell'
    ├───i686-linux: development environment 'nix-shell'
    ├───x86_64-darwin: development environment 'nix-shell'
    └───x86_64-linux: development environment 'nix-shell'

Meaning, you do not have to worry about what OS you using, as long as it's linux or macos. You write your nix flake with the ability to use it with all the supported platforms from the start for your environment. In other words, Write once, run on all the machines. No more of that 'it runs on my machine' debacle.

The last section is a let .. in pair to both declare what you will use in the system you are building and devShell itself. The packages use here are simply elixir, elixir-ls for sanity, and locales to make sure elixir is able to use the proper locale settings of the shell environment produced by the nix flake.

Finally, the devShell in this case is the buildInputs wanted for the shell environment and nothing more:

      {
        devShell = pkgs.mkShell {
          buildInputs = [
            elixir
            locales
          ]
      }

Notice while elixir-ls package isn't directly declared in the mkShell buildInput, it is part of the output on let. Allowing to still have linked access to its packages.

The full nix flake development environment

Finally, putting it all together, getting a nix flake project started for your development environment, all falls down to what packages you need on the devShell. With the flake.nix file on the root of your project, you have the ability to have the packages you need and ready for you to work with.

{
  description = "Development environment";

  inputs = {
    nixpkgs = { url = "github:NixOS/nixpkgs/nixpkgs-unstable"; };
    flake-utils = { url = "github:numtide/flake-utils"; };
  };

  outputs = { self, nixpkgs, flake-utils }:
   flake-utils.lib.eachDefaultSystem (system:
      let
        inherit (nixpkgs.lib) optional;
        pkgs = import nixpkgs { inherit system; };

        elixir = pkgs.beam.packages.erlang.elixir;
        elixir-ls = pkgs.beam.packages.erlang.elixir_ls;
        locales = pkgs.glibcLocales;
      in
      {
        devShell = pkgs.mkShell {
          buildInputs = [
            elixir
            locales
          ]
        }
      });
}

#elixir #development #nix #flakes

Bonus: Limiting by platform of choice your nix flake

Forty Four Keys of Joy

Alejandro Baez — Wed, 11 Nov 2020 02:19:13 +0000

A keyboard for software developers, system administrators, code junkies, writers, human being, and possibly cats is utmost important in this age. Do yourself a favor and get yourself a decent keyboard. Possibly if you read on, that may just be Keyboardio's Atreus.

Originally I thought the keyboard was a neat idea. I had a new need for a new keyboard and it's been a awful long while (read two years) since I had something decent. Not to mention, I suffer from what I am calling the Linux terminal syndrome. It is a deadly disease in which you tell everyone you use Linux and happen to also almost exclusively use a keyboard due to some bizarre hatred of mouses. Because of this lifetime choice, I am constantly typing and try as much as possible to take care of my hands. It is also to lessen the suffering from something very real like carpal tunnel or tendinitis. So I gave the team the good ol' funding on kickstarter.

It's been one month since my life has changed with Keyboardio's Atreus keyboard. The keyboard itself is forty four hardware keys in total. Take some time to leave that number to sink in... I'll wait....

Forty four keys.

FORTY FOUR KEYS.

OK. Why is the magic number such a big deal? So a normal keyboard has somewhere around 104 keys. What the team at Keyboardio did was look at a normal keyboard and say, “lol, NO.” These people went and cut down by more than half all the keys, yet figured a way to make you have more functionality on your existing keys than you can possibly ever need. Keyboardio went ahead like mad men, saw the potential of shifting to a different layer on a keyboard, and took it up a notch. You see, the keyboard has an ability to shift to different layers of which all the keys can be different to focus on what you need. So the 104 keys can be stuffed in just 3 layers on the keyboard, with spacing to spare.

Afterwards, Keyboardio went and then said, “You know what? Let's just add more layers, cause why not?” Thus, Atreus keyboard has the ability of holding nine layers of key definitions you can fully customize to whatever your needs or itch running at any time. The crazy people over at Keyboardio also made it so you can import and export the key definitions in structured JSON. Technically giving you endless formatting to your heart's content. So in case you somehow wanted to share your keys (I do and did, click here), you can with minimal effort.

Along with the customization, and there is definite more you can do with this, the Atreus design is what really makes sense for balanced sane typing. Since all the keys are layered on the forty four keys, your hand never reaches to press any key on the keyboard. This means none of that extended stretching to press the ESC key three meters away from the next key. It also features an ergonomic design that just makes sense. So much so that it feels very awkward touching another keyboard, which doesn't use the structure.

Lastly, and certainly not least, you can use BOX switches to make as much sound as mechanically possible. For me, this means using BOX red switches. Allowing me to keep my tradition of using my keyboard as if I'm playing a piano. Bundle all this in and you got yourself something almost healing to the touch. I dare say, you will probably be typing faster and smoother as time goes on.

The biggest piece to get and learn is the layout of the layering you set up. There was a lot of thought put into the original formatting. In other words, do fight the urge of customizing Keyboardio's choosing for Atreus layering layout. It will make the curve just that much easier to adapt towards. Then once you get a feel, start making it to your needs.

I'm still learning this little powerhouse, but I can safely say my typing has only gotten better without sacrificing my hands in the process.

Disclaimer: this whole article was written with the wondrous forty four keys of Atreus.

#keyboard #tooling #hardware

Tiling Managers Are Life

Alejandro Baez — Sat, 02 May 2020 03:37:29 +0000

I can't believe I thought I could go back to the window manager ways.

I don't even know how I convinced myself to try to use a machine without a Tiling manager, but that was the case back when I first tried out System76's Pop!_OS. Before I get to the why for Pop, let me give a little back story.

I been using Tiling Managers for almost a full decade. It all started with an obsession of a small, but definitely strong, embedded language called Lua.

Since the moment I learned of the language, I became absolutely obsessed with it. So much so, I wanted my whole software suite to be based on Lua. Everything from what I wrote personally, to what I wrote professionally, was in this language in one shape or another. It became such a large part of my way of being, to this day, Lua is the first thing I have installed on every machine that I can install it to. Be it work, home, servers, or things that compute, Lua is always there ready to help.

So when I was looking for some sort of desktop environment using the language, I learned of a tiling manager written in Lua; Awesome. The Awesome tiling manager is what would happen if you tried to mix ease of use with customization you can die for. You end up being in a place where you can make your desktop experience actually function as your desktop experience. A truly custom tailored tiling manager to your precise needs.

I was happy with Awesome. But being a polyglot by nature, I became in love with a different language in the coming years; Rust. Very much like my fascination with Lua, I ended up having a Rust written something, everywhere. Thus, when System76 announced Pop!_OS, they also announced it would have parts of its internals written in Rust. Nuff said. I ended up installing it on my machine and wait for it... actually like Gnome 3.

With the new love, my heart still ached from missing the tiling manager life of old. Ended up trying all the Gnome tiling manager extensions, but they just didn't feel right. Still, I stuck with gTile as the extension of choice for imitative Tiling management on Gnome 3.

However, with Pop's new release of 20.04, a full integrator level extension to gnome 3 has been made by the lovely lovely team in system76 for tiling management. Now it's not like Awesome, but I mean how could it be? Awesome is awesome for a reason. No, this released extension for Pop!_OS is based on i3. But boy is it outstanding. I definitely have a home with System76's work for years to come. Still learning the key bindings and tricks, yet you can very much see there was so much thought put in the tiling manager work. For crying out loud, the crazy team are even making a keyboard designed slightly different to augment the tiling manager use with their keyboard shortcuts. I'm absolutely sold.

If you still deciding whether you want to run a Tiling manager or not, stop what you doing. Install Pop!_OS. You'll Thank me later.

#100DaysToOffload #Day7