Directory structure

Table of contents

Introduction
What a full feature holds
What a feature with a server adds
Where features live
See also

Introduction

feature:create scaffolds the whole tree of a feature. This page shows what a full feature holds, what a feature with a server adds, and where features live on disk.

splent feature:create splent-io/splent_feature_notes

What a full feature holds

splent_feature_notes/
├── pyproject.toml              # Package metadata + feature contract
├── MANIFEST.in                 # Files to include in distribution
├── .gitignore
│
├── src/
│   └── splent_io/
│       └── splent_feature_notes/
│           ├── __init__.py     # Blueprint + init_feature() + inject_context_vars()
│           ├── config.py       # inject_config(app), env vars into app.config
│           ├── commands.py     # CLI commands for `splent feature:<name>`
│           ├── models.py       # SQLAlchemy models
│           ├── repositories.py # Data access (BaseRepository)
│           ├── services.py     # Business logic (BaseService)
│           ├── routes.py       # Flask routes
│           ├── forms.py        # WTForms
│           ├── decorators.py   # Feature-specific decorators
│           ├── hooks.py        # Template hook registrations
│           ├── seeders.py      # Database seeder (BaseSeeder)
│           ├── signals.py      # Signal handlers
│           │
│           ├── translations/   # i18n (.po/.mo per locale)
│           ├── templates/      # Jinja2 templates
│           │   ├── notes/      # Namespaced by blueprint
│           │   └── hooks/      # Hook fragments
│           ├── assets/         # Frontend (js/, css/, dist/)
│           ├── migrations/     # Per-feature Alembic
│           └── tests/          # Layered tests
│               ├── unit/
│               ├── integration/
│               ├── functional/
│               ├── e2e/
│               └── load/
│
└── docker/                     # Optional: a server of its own (feature:create --docker)
    ├── docker-compose.dev.yml  # The stack in development
    ├── docker-compose.prod.yml # The stack in production
    ├── Dockerfile.prod         # Optional: custom prod image
    └── .env.example            # Defaults, one per variable

At start, only the features your product declares go on sys.path, through its features/<org>/ links. A feature you do not declare cannot be imported, in development or in production.

What a feature with a server adds

A feature that needs an external service ships its own Docker files.

splent_feature_proxy/
└── docker/
    ├── docker-compose.dev.yml      # Dev: bind mount for live config editing
    ├── docker-compose.prod.yml     # Prod: builds custom image with baked config
    ├── Dockerfile.prod             # Copies templates into the image
    ├── .env.example                # Ports, upstream host, server name
    └── nginx/
        └── templates/
            ├── default.dev.conf.template
            └── default.prod.conf.template

feature:create --docker generates the two compose files and .env.example. The compose files are alternatives, one per environment, and product:up falls back to a plain docker-compose.yml when there is none for the environment. product:build copies Dockerfiles and supporting files into deploy/features/<service>/. Features that run a server has the full rules.

Where features live

Mode	Location	Permissions
Editable	The workspace root (`/workspace/splent_feature_notes/`)	Read-write
Pinned	The cache (`.splent_cache/features/splent_io/splent_feature_notes@v1.5.8/`)	Read-only

Your product reaches them through relative symlinks in <product>/features/<org>/. See Editable and pinned features.

Directory structure

Introduction

What a full feature holds

What a feature with a server adds

Where features live

See also