This blog post marks a change in my usage of Nix, I’m (just!) past the point of trying to get something to work and now starting to incorporate it into some of my regular workflows. So instead of trying to accomplish some major task, this post is a small collection of things I’ve learned over the past few weeks.
So far I’ve been learning how to use Nix by trying to package and define development shells for esbonio (see here if you are interested). While useful, the end result is not too dissimilar to what you can get with standard Python tooling. Indeed, the main reason I started looking into Nix was the promise of it being able to manage more than just Python libraries.
esbonio is a language server, it would be useful for Nix to create standardised environments where the language server is pre-configured for a given editor - great for debugging and demos!
In this blog post I try to define an environment in which Neovim is installed and configured to use the
esbonio language server for reStructuredText files.
It turns out there were a few issues with the setup I put together in my previous post. This time I try and resolve them and get to the point where I have working overlays for both pytest-lsp and esbonio.
Last time, I experimented with writing a flake that defined development environments for the esbonio package spanning multiple Python versions.
During that process I also packaged pytest-lsp using an ad-hoc nix expression as part of the
In this post I look into writing a similar flake for the
pytest-lsp package itself, but this time using overlays to override and extend the nixpkgs package set.
If you are interested, you can find the final version of the code here.
Personally, I’m most insterested in the package manager aspect and the promise of it being able to create declarative, reproducable development environments. With a configuration file and the nix develop command you can activate a kind of “virtual environment” that contains not just your Python packages - but any program defined by the configuration!
I find that idea particuarly exciting when working on a language server like esbonio, since it needs to be able to work against a variety of Python versions, Sphinx versions, as well as various code editors and all their versions! Having the ability to define a particular configuration and have some tool automatically recreate it would be amazing.
But I’m getting ahead of myself, let’s see if I can get to a point where I can easily test
esbonio against a range of Python versions.
Previously, as part of my exploration into how programming languages are implemented, I wrote a very simple AST evaluator that knew how to add and multiply floats together. Since constructing these ASTs by hand is quite painful I thought it would be fun to come up with a frontend to my “programming language” which could do it for me.
Now your typical frontend would be some kind of parser built into the compiler/interpreter. However, while I’m definitely interested in parsing I don’t quite feel like tackling that just yet. Instead I’m going to have Python be the frontend and embed my toy language into it via a CPython Extension
Today I Learned that Python’s standard library has a cmd module and it is awesome!
A few weeks back at PyConUK I gave my first lighting talk at a conference. During that talk I spoke publically about stylo for the first time. Stylo is a Python library that I have been working on for just over a year and a half and it aims to make the creation of images easier by bringing together ideas from programming and mathematics.
Version 0.6.0 was recently released which included the first feature that wasn’t written by me! It’s very exciting not only to see other people starting to take an interest in the project but taking the time to make a contribution!
Now that stylo seems to be getting to the point that it might me useful to other people wouldn’t it be great if there was a community driven example gallery that people could get inspired by? - Well now there is! And it’s called Stylo Doodles