Bio-Flow
- 2 Devlogs
- 14 Total hours
Bio-Flow is a bioinformatics library made in the Flower programming language that provides FASTA sequence tooling.
Bio-Flow is a bioinformatics library made in the Flower programming language that provides FASTA sequence tooling.
Been a while, hasn’t it? Anyways, some background context I feel is worth mentioning:
BioFlow was created for a research project of mine. Not for anything less specific, not to be used as a universal tool — though that’d be nice!
When I first made it, I realized pretty quickly that.. I’m not actually accomplishing anything for my research goal, but rather just trying to remake your generic Python Bioinformatics pipeline, which of course was not what I should focus on.
As such, you’ll notice the project in its entirety has been changed to reflect this.
There’s a LOT of changes, obviously. It’s around 10 hours worth of direct coding work (not counting all of the time spent doing research, gathering data, making decisions and creating formulas, etc.), and — as per usual — I didn’t break it up into multiple devlogs.
Instead, I locked in for 4 days, and now we have:
A computational analysis pipeline written mainly in Flower, which reads species metadata and protein annotations from TSV files, validates them, and exports candidate-family counts and normalized features. I used a C bridge for file access and numerical parsing.
Five initial candidate categories, specifically laccase-associated proteins, manganese peroxidase, lignin peroxidase, versatile peroxidase, and cytochrome P450 candidates.
Deduplication and conflict handling allows repeated hits and multiple annotation sources to not inflate the number of proteins counted, and proteins with competing family assignments are recorded as conflicting and excluded from the family counts.
Proteome-size normalization, where candidate counts are expressed per 1,000 predicted proteins, whilst preserving the raw counts. Missing, zero, or inconsistent denominators produce (clearly marked!) missing values.
So yea, that’s what’s been happening. Eventually I’ll link the paper to this somehow, and of course keep the analysis pipeline open source completely for reproducible results and independent verification!
Thanks for reading, much love <3
Date: 2026-07-22
Instead of jumping right into code — like I normally do — I decided to instead write documentation on how the project would be handled from a development standpoint. This included deciding on things such as Semantic Versioning, Conventional Commits, short-lived branches, and squash merges. None of it was particularly original, but the point was to remove any ambiguity regarding the actual developm from the actual work. I no longer need to wonder whether a feature belongs directly on main, what a release branch will be named, or whether generated binaries should be comitted.
I also decided that CHANGELOG.md would remain at the root similar to the README, and other policy documents / actual project-facing documentation would live under docs/.
The original CLI I wrote walked over every argument and then tried to interpret options and commands inside that very same loop. This causes conflicts and issues, especially relating to reading a filepath that might not exist in argv.
I replaced it with the rule that one invocation has one command, and everything after it belongs to that command.
The accepted shape thus is now:
bioflo <command> [arguments]
Commands may officially be written with zero, one, or two leading dashes — though any amount of dashes is current accepted. Dash removal is bounded rather than handled by an open-ended pointer loop, so inputs such as - and -- cannot be walked beyond the end of the string.
Testing this produced a strange error where for whatever reason my system got stuck on a kernel write request, which froze all other kernel requests and muddied any other programs from running in my terminal. I restarted my computer and that was that. Really annoying because for like 20 minutes I thought the issue was me. It was not.
The first actual library module handles basic DNA sequences.
Currently, a valid sequence can contain A, C, G, T, and N. I chose to accept N because unknown bases are common in real sequence data — from personal experience. Lowercase input is rejected rather than normalized implicitly purely just because I haven’t gotten to it yet. Empty strings are invalid sequences, but I did make it so that GC content for an empty string returns 0.0 to avoid division by zero.
GC content is returned as a fraction between 0.0 and 1.0, not as a percentage. This is to keep the value reusable rather than prioritize presentability.
I deliberately kept the public API small for now as to avoid overextending the first release:
is_valid_dna
count_nucleotide
gc_count
gc_content
The base-checking helper I have kept private. This is my first attempt at treating prop as an explicit public-facing endpoint rather than using it for everything.
Version 0.1.0 is by no means a feature-complete release (obviously). It’s my first steps at not only making a specific library for bioinformatics, but also testing Flower’s ability to even create usable libraries.
The CLI still does not read files, FASTA parsing does not yet exist, and case normalization / additional ambiguity codes are also deferred.
In the coming planned work, I intend for Bio-Flow to reach a somewhat usable state in the hopes of utilizing it for some of my own personal projects :)