---
title: Tempera
shorttitle: Tempera
slug: tempera
date: 03/27/2026
thumbnail: '/thumbnails/brush.png'
tag: python
canonicalUrl: 'https://sanjaycnagi.com/blog/2026-03-27-tempera/'
---

![Signac - Les Diablerets, 1903](https://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/Signac_-_Les_Diablerets_%28L%27Oldenhorn_et_le_B%C3%A9cabesson%29%2C_1903%2C_lot-5334957.jpg/1280px-Signac_-_Les_Diablerets_%28L%27Oldenhorn_et_le_B%C3%A9cabesson%29%2C_1903%2C_lot-5334957.jpg)

Inspired by a February visit to Florence and it's rich history of renaissance art, I recently developed a Python package, [*Tempera*](https://sanjaynagi.github.io/tempera/), that provides Python colour palettes for major Python plotting tools, extracted from major historic artworks. 

*Tempera* is an artistic medium made by mixing pigments with a water-soluble emulsion, often made of water and egg yolk. It was one of the primary painting techniques of the pre and early Renaissance periods — Botticelli's [The Birth of Venus](https://en.wikipedia.org/wiki/The_Birth_of_Venus), for instance, is egg tempera on canvas.

Tempera

---
title: Don't use Conda, use Pixi!
shorttitle: Don't use Conda, use Pixi!
slug: use-pixi
date: 01/16/2026
thumbnail: '/thumbnails/prefix.png'
tag: package-management
canonicalUrl: 'https://sanjaycnagi.com/blog/2026-01-16-use-pixi/'
---


The bioinformaticians amongst will be familiar with the Conda package manager - for a long time, it has been the go to package management tool in the world of open source software. It allows us to install, update, and manage software packages and their dependencies across multiple programming languages, whilst creating isolated environments so different projects can use different package versions without conflicts. Whilst incredibly useful as a tool, Conda is also notorious for being extremely slow, heavy on storage, and mixing Conda with pip (the Python package manager) can often lead to cryptic dependency conflicts which are hard to debug. 
 
**Enter Pixi 🧚 !**    
Pixi is a modern re-thinking of Conda, developed by the team at [prefix.dev](https://prefix.dev/) (some of whom developed Conda itself). At its core, Pixi uses the same underlying ecosystem of Conda packages, primarily from the conda-forge and bioconda repositories, but rethinks how environments are created, solved, and shared.

**Blazing fast 🚀**  
Pixi is built on top of rattler, a modern dependency resolver written in Rust. In practice, this makes environment resolution dramatically faster than classic Conda, which was written in Python. Rattler also uses a much more efficient solver implementation, and all of this this means that creating or updating environments feels almost instantaneous.

**Lockfiles 🔒**  
Pixi also introduces lockfiles, a now well-established concept that was first popularised in the JavaScript ecosystem, most notably with npm's package-lock.json and yarn's yarn.lock. These tools recognised early on that simply specifying version ranges (e.g. ^1.2.0) was not enough to guarantee reproducible installs, because transitive dependencies could still change underneath you. Lockfiles solved this by recording the exact dependency graph that was resolved at install time. The mottivation is to separate intent from resolution - that is, a main config file (pixi.toml) expresses what you want, while the lockfile records what you actually got.

Pixi applies this pattern to the Conda world, where reproducibility has traditionally been much harder to achieve. Classic Conda environment files specify dependency ranges but leave resolution to the solver each time, meaning two installs on different days or machines can yield subtly different environments. Pixi’s lockfile approach brings Conda in line with modern package managers by making environment resolution deterministic, shareable, and ultimately more reproducible.

**A project-centric workflow 📁**   
Pixi encourages a clean, project-based way of working. Each project lives in its own directory with a pixi.toml file describing dependencies and tasks, alongside a lockfile that captures the resolved environment. There is no global “base” environment to accidentally break, and the structure of a project is immediately clear to anyone new to it. This fits naturally with modern development practices and makes projects easier to share, version-control, and archive.

**Safer pip integration 🧪**  
Mixing Conda and pip has historically been a source of subtle and painful bugs. Pixi makes this safer by being explicit about pip dependencies and capturing them in the lockfile alongside Conda packages. You still get the flexibility of pip, but with much better guarantees that your environment will remain consistent.

---

I’ve now been using Pixi for the past 6 months or so, and it has made life as a data scientist much more convenient. If you use Conda a lot, Pixi is well worth exploring.


Don't use Conda, use Pixi!

---
title: "Moving to EIT"
shorttitle: "Moving to EIT"
slug: moving-to-eit
date: 01/15/2026
thumbnail: '/thumbnails/eit.png'
tag: personal
canonicalUrl: 'https://sanjaycnagi.com/blog/2026-01-15-moving-to-eit/'
---

A belated update to share some news: I've recently moved to the [Ellison Institute of Technology](https://eit.org/) to join the pathogen programme. 

I’m incredibly grateful for my time at LSTM, where I spent the early years of my scientific career and was able to work with many great people on problems in vector control and vector genomics. I’ve been lucky to grow there as a scientist, and to form friendships with outstanding colleagues from around the world (please keep in touch!). After nine years at the school, however, I felt ready for a new challenge.

At EIT, we are developing next-generation tools in improve and transform the diagnosis of infectious pathogens. It's an ambitious aim, but the programme is already packed with brilliant people and I'm excited to be a part of it and to see what we can achieve! We are actively looking for forward-thinking, driven data scientists and data engineers - if that sounds like you, then please get in touch.


Moving to EIT

---
title: "The malaria vector selection atlas"
shorttitle: "The malaria vector selection atlas"
slug: selection-atlas
date: 07/21/2025
thumbnail: '/thumbnails/atlas.png'
tag: malariagen_data, genetics
canonicalUrl: 'https://sanjaycnagi.com/blog/2025-07-21-selection-atlas/'
---

[![selection atlas signals](/blog/signals.png)](doi.org/10.1101/2025.07.16.664900)

Dual-active ingredient ITNs are now being deployed in sub-Saharan Africa. We know that these nets are not only highly effective but effective against pyrethroid-resistant malaria vectors, which should help in the fight against malaria. But given the evolutionary adaptability of malaria mosquitoes, we must rapidly find ways to detect resistance before it becomes widespread, in order employ insecticide resistance management practices and protect the lifespan of these critical tools. 

When a beneficial mutation arises — like one that helps a mosquito survive insecticide exposure — it begins to spread through a population, leaving a signature of reduced genetic diversity around it. We can exploit this signature to pinpoint regions of the genome that are under selection and threatening malaria vector control efforts. 

In a new pre-print on [bioRxiv](https://www.biorxiv.org/content/10.1101/2025.07.16.664900), we present a web resource, the [**Malaria Vector Selection Atlas**](https://anopheles-genomic-surveillance.github.io/selection-atlas/), a database of selection signals in wild Anopheles mosquitoes within the [Vector Observatory](https://www.malariagen.net/vobs/). We analysed whole-genome sequence data from over 4,300 mosquitoes collected across 21 African countries, using population genomic methods to scan the genomes of our cohorts for telltale signs of recent positive selection. The atlas reveals both familiar loci and new threats: we confirm selection at established resistance genes like the *Vgsc* (the target of DDT and pyrethroids) and metabolic enzyme clusters like the *Cyp6p* locus that break down insecticides. But we also discovered novel signals including a diacylglycerol kinase on the X chromosome that may represent a previously unknown resistance mechanism. The selection atlas is powered by an automated computational workflow that enables continuous updates as new data become available. As we integrate more recent data, we envisage that the resource will provide a crucial early warning system for tracking mosquito evolution in near real-time, helping to inform evidence-based decisions about where and how best to deploy our limited vector control tools.
 
---

*Explore the pre-print on [bioRxiv](https://www.biorxiv.org/content/10.1101/2025.07.16.664900v1) and the [selection-atlas web resource](https://anopheles-genomic-surveillance.github.io/selection-atlas/)*


The malaria vector selection atlas

---
title: "AnoKin: Using genomics to estimate dispersal in malaria mosquitoes"
shorttitle: "AnoKin: a close-kin mark-recapture study"
slug: anokin-ckmr-dispersal
date: 03/05/2025
thumbnail: '/thumbnails/dispersal.png'
tag: ckmr, dispersal
canonicalUrl: 'https://sanjaycnagi.com/blog/2025-03-05-ckmr-dispersal/'
---

![anokin logo](/blog/anokin-logo.png)

---

Despite hundreds of years of research, we do not understand how far the malaria mosquito can fly.

This is challenging for many reasons. How can we design a cluster randomised controlled trial (cRCT), without knowing if mosquitoes will fly from a control cluster into an intervention cluster? How can we model the spread of gene drives without knowing how far a single mosquito could transport the drive? 

---

Last year, I was awarded some funding from the [Liverpool School of Tropical Medicine](http://lstmed.ac.uk/) to work on this problem, as part of their [Directors Catalyst Fund](https://www.lstmed.ac.uk/study/research-degrees/director%E2%80%99s-catalyst-fund-0). The idea was to use a genomic approach known as close-kin mark-recapture (CKMR). The method is analogous to traditional mark-release recapture, except rather than marking individuals and releasing them, we use kin to mark each other. We sequence mosquitoes, infer their kinship, and use the distances between kin to estimate how far they disperse. It was first developed in fisheries science, and has many applications; it can be used to investigate dispersal, but also population size as well as survivorship. 

For the last couple of weeks, I have been based in Kisumu, western Kenya, working with Dr Eric Ochomo's team and Brian Polo of the [Kenya Medical Research Institute (KEMRI)](https://www.kemri.go.ke/) to set up the sampling. We are working at Lake Kanyaboli, a site of high malaria transmission that provides a stable habitat for the malaria mosquito *Anopheles funestus* throughout the year. Everything is going super well so far - I am really fortunate to be working with an awesome team!

#### The AnoKin site

In the spirit of transparency, part of my proposal was to set up a [public-facing website for AnoKin](https://sanjaynagi.github.io/anokin/). The site contains some background to the project, some protocols, and important links for the field team.

In ultimate nerdiness 😎, I've set up a [daily GitHub actions](https://github.com/sanjaynagi/anokin/blob/main/.github/workflows/docs-auto.yml) which downloads the sampling and morphological ID data from the ODK server where we store data. It then runs a jupyter notebook to perform some analysis, and re-builds and re-publishes the [webpage](https://sanjaynagi.github.io/anokin/). 

So far, the sampling is going really well. Numbers are relatively low for Lake Kanyaboli, but this may actually be a positive - sampled mosquitos are probably more likely to be related. Follow along on here and the AnoKin website, where I'll post regular updates as our project attempts to yield new insights into mosquito dispersal.

Hey, I'm Sanjay

Latest Posts

Get in Touch