Work ICV OSS: An Open-Source Django Package …
Project · ICV OSS

ICV OSS: AN OPEN-SOURCE DJANGO PACKAGE ECOSYSTEM

Seven open-source Django packages on PyPI plus a private catalogue, each its own repository with independent CI and release cycle, so projects adopt infrastructure instead of rebuilding it.

Duration
2025-Present
Role
Founder & Lead Developer
Stack
Django Django REST Framework GitHub Actions Meilisearch PostgreSQL PyPI Trusted Publishing Python Redis
ICV OSS: An Open-Source Django Package Ecosystem
Key results
  • Scale: 7 public PyPI packages plus a private catalogue served from a self-hosted index

Overview

ICV OSS is a family of reusable Django packages I build and maintain. Every package is a standalone git repository with its own GitHub remote, CI pipeline, and release cycle, grouped under a single documentation umbrella. Seven packages are open source and published on PyPI; a further catalogue of packages is developed privately and graduates to public when a real consuming project needs it.

The point is simple: consuming projects should adopt a package rather than reinvent one. Multi-tenancy, search, tree structures, taxonomy, sitemaps, a web application firewall: these are solved once, versioned properly, and reused everywhere.

The Problem

Across every Django project I run, the same infrastructure kept getting rebuilt from scratch: row-level tenancy, full-text search, materialised-path trees, SEO discovery files, bot protection. Each rebuild was a little different, a little worse, and impossible to fix in one place.

Factoring these into independently-released packages means a fix or an improvement lands once and every project picks it up on its next dependency bump.

The Approach

The umbrella repository tracks only shared documentation and templates. Each package lives in its own repository so it can be versioned, tested, and released on its own cadence.

The ecosystem follows a deliberately flat dependency topology: cross-package dependencies resolve only through PyPI, never through sibling paths, and django-icv-core is never a hard dependency (packages integrate with it behind an optional extra with guarded fallbacks). Releases are tag-push driven, publishing to PyPI through OIDC trusted publishing, and CI refuses to publish without a matching changelog entry.

Private packages are served from a self-hosted index and promoted to the public track only on real demand, so the public surface stays small and genuinely reusable.

The Public Packages

  • django-boundary: row-level multi-tenancy for Django with PostgreSQL RLS, standalone and not ICV-branded.
  • django-icv-core: the base layer: abstract base models, managers, middleware, and an opt-in audit subsystem.
  • django-icv-search: pluggable full-text search with swappable backends (Meilisearch, PostgreSQL, and others) plus a merchandising layer.
  • django-icv-sitemaps: scalable sitemaps plus robots.txt, llms.txt, ads.txt, and security.txt, fully standalone.
  • django-icv-tree: a materialised-path tree library: TreeNode, TreeManager, and move/rebuild services.
  • django-icv-taxonomy: cross-domain taxonomy, vocabularies, and tagging, built on django-icv-tree.
  • django-waf: a self-hosted web application firewall with bot detection, rate limiting, and challenge flows.

Results

  • Seven open-source packages live on PyPI, each independently versioned and released.
  • A private catalogue served from a self-hosted index, promoting packages to public only on real demand.
  • A strict flat dependency topology that keeps every package usable on its own.
  • A spec-first, precedence-ordered workflow shared across every repository.
Tags
Django Python Open Source Developer Tools Multi-Tenancy PyPI
Repository
GitHub →
Interested?

Get in touch to discuss how I can help with your project.

Start a conversation
More work
All projects →

GOT A PROJECT?
LET'S TALK.

£900/day · Available for projects · Usually responds within 24 hours

Start a conversation