DataTalks.Club website

This repository is the deliberately small Django foundation for the unified DataTalks.Club website. The architecture and migration requirements live in _docs/specs/, and contribution work follows _docs/PROCESS.md.

Prerequisites

• Python 3.13 or newer (selected automatically by uv)
• uv
• Chromium installed by the setup target for browser tests

Bootstrap

cp .env.example .env
# Replace the local secret placeholder, then:
make setup
make migrate
make run

The local site is served at http://localhost:8000. Local development uses the gitignored .tmp/local.sqlite3 database by default. Set DTC_SQLITE_PATH to use another SQLite file; relative paths resolve from the repository root. No development host is deployed at the moment: the web.dtcdev.click stack was decommissioned on 2026-09-02 and its replacement dev.datatalks.club is not built yet. deploy/development_target.py holds the reviewed development hostnames and selects one from DTC_DEVELOPMENT_HOSTNAME; a deployed development host is always marked noindex, nofollow.

Local administrator

Seed the shared local-only administrator and placeholder social providers after migrating the database:

uv run python scripts/create_local_admin.py

Log in with admin@aishippinglabs.com / admin123. These intentionally weak, checked-in credentials are only for local testing. The script refuses to run outside the local runtime or against a non-SQLite database, and each run restores the documented password and administrator privileges. It also enables the Google, GitHub, and Slack buttons on the local sign-in and sign-up pages using inert placeholder OAuth credentials. The buttons are for visual testing and intentionally cannot complete authentication with the external providers.

Local course data

A freshly migrated database has no courses, while the homepage renders its course catalogue from the checked public projection in content/public_projection/courses.json. Seed the database so / and /courses show the same real courses:

uv run python manage.py seed_local_courses          # write the catalogue
uv run python manage.py seed_local_courses --check  # validate without writing

The command writes the 12 real cohorts, their homework titles, and their deadlines from scripts/production_like_course_specs.json, the pinned DataTalksClub/course-management-platform@98a2352 catalogue that the public projection is also built from; it verifies that file's SHA-256 and refuses to run if the projection and the catalogue would disagree. It is repeatable, creates no learners, enrollments, or submissions, and preserves operational state you have set locally (homework/project state, registration URLs, scoring flags). It is a development tool: it refuses to run outside a local or test SQLite database. Generating production-like participants, submissions, and leaderboards remains uv run python scripts/generate_production_like_leaderboard_data.py.

To exercise the DE Zoomcamp Project 1 submission and peer-review routes locally, run the separate synthetic scenario seed:

uv run python manage.py seed_local_project_review

It creates six realistic-but-synthetic submissions under the example namespace, assigns peer reviews with the existing assignment service, and moves Project 1 into peer review. It is repeatable, reports counts and state only, and refuses to overwrite non-synthetic submissions or run outside local/test SQLite.

Public projection images

The 1,253 public projection images (/images/..., about 154 MB) are not tracked in git. A fresh clone renders every page except the artwork, and manage.py check warns with the command to run:

uv run --frozen python scripts/prod/sync_public_media_hydrate.py

Hydration is idempotent, verifies every object against its recorded checksum, and needs no AWS credential. The default local backend then serves the real bytes at the unchanged URLs. See the public media runbook for the backends, the operator publish/verify flow, and what a 502 on an image means.

Local development and ordinary CI require no PostgreSQL installation or service. Tests always use isolated SQLite and ignore an ambient DATABASE_URL. Deployed development and production continue to use PostgreSQL/RDS through their fail-closed settings and deployment migration/readiness/smoke path.

Common commands

make lint
make format-check
make typecheck
make migrations-check
make deployment-check
make content-update-check
make test-core
make test-playwright-core
make test
make worker

Every Python command is run through uv, either directly or by these Make targets. Do not use pip for this project. Temporary artifacts belong under .tmp/; .env, databases, screenshots, browser state, and secrets are gitignored.

Configuration

Settings modules are:

• website.settings.local: local development with project-local SQLite.
• website.settings.test: deterministic isolated SQLite for ordinary tests and checks.
• website.settings.development: the hostname selected by deploy/development_target.py; production-shaped and always non-indexable.
• website.settings.production: production security settings and fail-closed bootstrap configuration. prod.datatalks.club is staging for its whole life while the apex still serves the legacy corpus, so these settings are non-indexable and account links resolve on the served host while canonical links stay on the apex.

deploy/deployment_targets.py holds the reviewed deployment targets — account, region, hostname, resource namespace, settings module, desired counts and secret shapes for each applied stack. DTC_DEPLOYMENT_TARGET selects one from that in-code allowlist; an unreviewed or retired name fails closed, and so does a stack whose real identifiers disagree with the reviewed profile.

Deployed development and production require a non-placeholder secret, a PostgreSQL DATABASE_URL, allowed hosts, and trusted CSRF origins. Readiness checks the database, unapplied migrations, and these bootstrap settings without calling GitHub, AWS, email, or any other optional provider. The retained psycopg dependency is for these deployed processes only; application services and migrations use portable Django contracts exercised on SQLite.

See _docs/architecture/app-boundaries.md for dependency direction, _docs/architecture/database-portability.md for the database boundary and remaining-term inventory, the content-update runbook for the checked projection lane, the public media runbook for the projection image objects, and _docs/contributing.md for the full contribution handoff.