Add basic Flask app structure

# Python-related

venv

**/__pycache__

.ipynb_checkpoints

# JavaScript-related

package.json

package-lock.json

node_modules

# Tests

.coverage

.pytest_cache

htmlcov

testresults.xml

cypress/videos

# PyCharm configuration

.idea

# VS Code configuration

*.code-workspace

# Local instance data and configuration

instance

# Environment files (might contain secrets)

.env

# Git and Docker

.git

.gitlab-ci.yml

.dockerignore

.gitignore

Dockerfile

.prettierignore

.prettierrc.json

# Python-related

venv

__pycache__

.ipynb_checkpoints

# JavaScript-related

node_modules

# Tests

.coverage

.pytest_cache

htmlcov

testresults.xml

cypress/videos

# PyCharm configuration

.idea

# VS Code configuration

*.code-workspace

# Local instance data and configuration

instance

# Environment files (might contain secrets)

.env

FROM nginx:latest

FROM python:3.12 AS base

RUN sed -i -E "s#(application/javascript\s+js);#\1 mjs;#" /etc/nginx/mime.types

# We will use /app as our main directory within the Docker container

WORKDIR /app

EXPOSE 5000

COPY . /usr/share/nginx/html

# First, copy and install only the requirements...

RUN pip install --upgrade pip setuptools

COPY requirements.txt .

RUN pip install -r requirements.txt

# ... then the rest of the application. This allows the installation stage to be cached most of the time

# (so we don't have reinstall of all dependencies every time the container is rebuilt)

COPY . .

FROM base AS dev

ENV SERVER_TYPE=flask

ENV FLASK_DEBUG=true

ENV FLASK_APP=portal

CMD ["bash", "./entrypoint.sh"]

FROM base AS prod

ENV SERVER_TYPE=uwsgi

RUN pip install uwsgi

CMD ["bash", "./entrypoint.sh"]

# A generic, single database configuration.

[alembic]

# path to migration scripts

script_location = alembic

# template used to generate migration file names; The default value is %%(rev)s_%%(slug)s

# Uncomment the line below if you want the files to be prepended with date and time

# see https://alembic.sqlalchemy.org/en/latest/tutorial.html#editing-the-ini-file

# for all available tokens

# file_template = %%(year)d_%%(month).2d_%%(day).2d_%%(hour).2d%%(minute).2d-%%(rev)s_%%(slug)s

# sys.path path, will be prepended to sys.path if present.

# defaults to the current working directory.

prepend_sys_path = .

# timezone to use when rendering the date within the migration file

# as well as the filename.

# If specified, requires the python-dateutil library that can be

# installed by adding `alembic[tz]` to the pip requirements

# string value is passed to dateutil.tz.gettz()

# leave blank for localtime

# timezone =

# max length of characters to apply to the

# "slug" field

# truncate_slug_length = 40

# set to 'true' to run the environment during

# the 'revision' command, regardless of autogenerate

# revision_environment = false

# set to 'true' to allow .pyc and .pyo files without

# a source .py file to be detected as revisions in the

# versions/ directory

# sourceless = false

# version location specification; This defaults

# to alembic/versions.  When using multiple version

# directories, initial revisions must be specified with --version-path.

# The path separator used here should be the separator specified by "version_path_separator" below.

# version_locations = %(here)s/bar:%(here)s/bat:alembic/versions

# version path separator; As mentioned above, this is the character used to split

# version_locations. The default within new alembic.ini files is "os", which uses os.pathsep.

# If this key is omitted entirely, it falls back to the legacy behavior of splitting on spaces and/or commas.

# Valid values for version_path_separator are:

#

# version_path_separator = :

# version_path_separator = ;

# version_path_separator = space

version_path_separator = os  # Use os.pathsep. Default configuration used for new projects.

# set to 'true' to search source files recursively

# in each "version_locations" directory

# new in Alembic version 1.10

# recursive_version_locations = false

# the output encoding used when revision files

# are written from script.py.mako

# output_encoding = utf-8

[post_write_hooks]

# post_write_hooks defines scripts or Python functions that are run

# on newly generated revision scripts.  See the documentation for further

# detail and examples

# format using "black" - use the console_scripts runner, against the "black" entrypoint

# hooks = black

# black.type = console_scripts

# black.entrypoint = black

# black.options = -l 79 REVISION_SCRIPT_FILENAME

# lint with attempts to fix using "ruff" - use the exec runner, execute a binary

# hooks = ruff

# ruff.type = exec

# ruff.executable = %(here)s/.venv/bin/ruff

# ruff.options = --fix REVISION_SCRIPT_FILENAME

# Logging configuration

[loggers]

keys = root,sqlalchemy,alembic

[handlers]

keys = console

[formatters]

keys = generic

[logger_root]

level = WARN

handlers = console

qualname =

[logger_sqlalchemy]

level = WARN

handlers =

qualname = sqlalchemy.engine

[logger_alembic]

level = INFO

handlers =

qualname = alembic

[handler_console]

class = StreamHandler

args = (sys.stderr,)

level = NOTSET

formatter = generic

[formatter_generic]

format = %(levelname)-5.5s [%(name)s] %(message)s

datefmt = %H:%M:%S

# Alembic

This project uses Alembic for database migrations, i.e. creating, updating and deleting table schemas in the database.

The migrations are _run_ automatically when starting the application (e.g. at the first start ever, a migration is run that “migrates” from an empty database to the way it should currently be; similarly, if you've pulled in an update of the code that requests e.g. a new table or a new column, the database is updated by creating the new table or column, respectively).

However, you need to _create_ the migrations semi-automatically. This always becomes necessary when you code and change something about the model. After you are satisfied with the changes, you need to run:

```bash

alembic revision --autogenerate -m "<A description of the model changes>"

```

This will automatically generate a new Python file in `versions/`, which will include an upgrade and a downgrade method for the database. Ideally, you can use this file without further changes, however, please check it first (depending on the current layout of your database, it might very well be possible that Alembic generates more commands than needed).

After having modified the file, you commit everything (i.e. your model changes and the generated migrations).

## Further reading

-   https://alembic.sqlalchemy.org/en/latest/tutorial.html

-   https://alembic.sqlalchemy.org/en/latest/autogenerate.html