Challenge 1: Create Your First Project and App — Possible Solution
====================================================================

# 1. Install Django (ideally inside a virtual environment)
pip install django

# 2. Create the project
django-admin startproject library
cd library

# 3. Create the app inside it
python manage.py startapp catalog

RESULTING FILE STRUCTURE
------------------------

library/
├── manage.py
├── library/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   ├── wsgi.py
│   └── asgi.py
└── catalog/
    ├── __init__.py
    ├── admin.py
    ├── apps.py
    ├── models.py
    ├── tests.py
    ├── views.py
    └── migrations/
        └── __init__.py

WHAT EACH FILE IS FOR
----------------------
- manage.py — the command-line entry point for the whole project: running
  the dev server, applying migrations, opening a shell, running tests.

- library/settings.py — the project's single configuration file: database
  connection, INSTALLED_APPS, middleware, templates, static files.

- library/urls.py — the project's root URL routing table; typically
  includes each app's own urls.py rather than listing every route directly.

- library/wsgi.py / asgi.py — the two production entry points (synchronous
  vs asynchronous) that a real web server (gunicorn, uvicorn, etc.) uses to
  actually run the project; not touched during normal development.

- catalog/models.py — where the app's database tables are defined, as
  Python classes (empty until you add your first model).

- catalog/views.py — where the app's request-handling logic lives —
  functions or classes that take a request and return a response.

- catalog/admin.py — where models get registered so they automatically
  appear in Django's built-in admin interface (nothing appears there
  until a model is explicitly registered here).

- catalog/apps.py — a small configuration class Django uses to identify
  and configure the app itself (rarely edited directly for a simple app).

- catalog/tests.py — where the app's automated tests go, using Django's
  TestCase-based testing framework.

- catalog/migrations/ — an auto-generated, ordered history of schema
  changes for this app's models; starts with just __init__.py until the
  first `makemigrations` run.

WHY THIS WORKS
--------------
- `django-admin startproject` only needs to run once per project — it
  creates the outer configuration shell (settings, root urls, entry
  points) that every app inside the project will share.
- `python manage.py startapp` is run once per distinct feature/app — a
  single project commonly contains several apps (catalog, accounts,
  orders, ...), each focused on one area of functionality.
- Notice that `catalog` on its own does nothing yet — per Challenge 2, an
  app's files exist on disk immediately, but Django doesn't actually
  treat them as part of the project until they're added to
  INSTALLED_APPS in settings.py.