Go to file
2025-07-16 21:21:41 +02:00
.vscode file was created while setting up Python environment within VSCodium 2025-07-15 23:15:09 +02:00
the_works make applying config values more robust 2025-07-16 21:21:41 +02:00
utils these are all files of lesser importance 2025-07-15 23:14:07 +02:00
.flaskenv changed how the app gets its config values 2025-07-16 17:21:14 +02:00
.gitignore added ".vscode" directory and any ".env" file 2025-07-16 17:10:39 +02:00
README.md added info about configuring the app 2025-07-16 17:48:37 +02:00
requirements.txt moved dependency information to README.md; added file "requirements.txt" that was generated with pipreqs 2025-07-15 23:10:53 +02:00
tmp.md these are all files of lesser importance 2025-07-15 23:14:07 +02:00
works.oldschema.sqlite these are all files of lesser importance 2025-07-15 23:14:07 +02:00

The Works

Configuration

The file .flaskenv contains the default configuration. Flask reads the file at startup and adds the contained key-value-pairs as environment variables to the runtime environment. When the Flask app object is being created in __init__.py, all environment variables that start with the prefix "FLASK_" are added to the app configuration. This is true for any prefixed environment variable, not just the ones from .flaskenv.

Configuration values can be overridden by passing another config file to Flask via the -e command line switch. It will be processed the same way as .flaskenv, which means that all keys must be prefixed with "FLASK_", and takes precedence over the default configuration.

Finally, you can override config settings while instantiating the Flask app through the factory. To do this, simply pass a dictionary with the (unprefixed) override settings as named parameter config to the create_app() method. Settings passed this way take precedence over the default configuration and an optional config file.

Flask commands

Execute commands with python -m flask <command>. You don't need to specify --app the_works as long as the environment variable "FLASK_APP" is set to "the_works"; the default configuration file does this.

Available commands:

  • run: Serve app (don't use for production).
  • shell: start a shell within the app context (I can i.e. import specific table models and test the data structures returned by ORM methods like select())

Dependencies

Python Packages

flask flask-sqlalchemy python-dotenv Pillow pytest flask-debugtoolbar (optional)

CSS and Javascript

PicoCSS (regular version) + SwitchColorMode.js (from Yohn's fork) DataTables.[js|css]

Icons

some icons from heroicons.com

Other useful stuff

Export database schema

Method 1: sqlite3 the_works.sqlite .schema > outputfile.sql

Method 2: Open DB in SQLitebrowser and use File -> Export -> Database to SQL file …

  • keep original CREATE statements
  • export schema only
  • overwrite old schema (DROP TABLE, then CREATE TABLE)

Generate declarative SQLAlchemy code

Right now the_works reflects an existing database in order to infer the underlying data models for SQLAlchemy. If I wanted to declare the data models directly instead of using reflection, I would need declarative code. This code can be generated from an existing database with the help of sqlacodegen:

sqlacodegen sqlite:///path/to/db.sqlite > outputfile.py

Generate requirements.txt

I use pipreqs to generate the file requirements.txt. The package scans all source files for import statements and uses those to extract all required Pip packages.