Add a CLI Wrapper for Django Project Initialization #75

zahraaalizadeh · 2024-11-22T05:47:33Z

Description

This PR introduces a CLI wrapper named booster to simplify the process of initializing Django projects:

Simplifies project initialisation with reusable configurations.
Introduces flexibility for customising templates and project variants.
Lays the groundwork for future CLI enhancements.

Key updates

Add CLI Wrapper: Implements a command-line interface (booster) for generating Django projects based on a YAML configuration file.
Dynamic Template Rendering:

Replaces the use of django-admin startproject with direct rendering of templates using Jinja2.
Supports dynamic customisation of directory names, file names, and content based on config file values.
Handles Django-specific template tags (e.g., verbatim) using Jinja2’s raw tag for compatibility.

Configuration: Default configuration file is sample_config.yml.
Package Creation:

Converts the CLI into an installable Python package.
Includes packaging instructions with pyproject.toml for pipx installation.

Documentation Updates:

Updates the README to reflect the new CLI usage.
Records architectural decisions in an ADR document.

Housekeeping: Adds .gitignore entries for build artifacts and output folders.

zahraaalizadeh · 2024-11-22T05:56:59Z

I noted I need to update the project CI properly. I'll fix it some time next week.

a-musing-moose · 2024-11-24T22:22:26Z

Question: Do you need to replace startproject entirely?

Could you just wrap it in your script then perform additional steps after startproject has finished?

This change adds a simple wrapper for startproject command of django. It generate the project based on the config file.

After this change, the path to the project can be configured in the config file. If the path doesn't exists it creates the path. If the path exists, it prompts the user to confirm a fresh start or abort.

zahraaalizadeh · 2024-11-29T07:41:05Z

@a-musing-moose Thanks for the review! My initial idea was to use Jinja2 for rendering settings dynamically, but I agree that sticking with startproject provides a more straightforward and familiar approach. I’ve updated the PR so the CLI tool now acts as a simple wrapper around startproject. In upcoming PRs, I’ll focus on post-processing steps, such as custom database setup and other enhancements. Let me know if there’s anything you’d like me to prioritise or adjust. 😊

a-musing-moose · 2024-12-01T21:22:00Z

src/booster.py

+from pathlib import Path
+
+import typer
+import yaml


nitpick (non-blocking): ‏Can we use toml instead?

I have a pet peeve about yaml - I find it hard to format correctly for some reason. Toml is a simpler standard, we already use it (pyproject.toml) and as an added bonus - reading toml is built into recent versions of Python: https://docs.python.org/3/library/tomllib.html

That's a good point. I'll update it.

a-musing-moose · 2024-12-01T21:23:50Z

pyproject.toml

+license = {text = "BSD-3-Clause"}
+dependencies = [
+    "typer[all]>=0.9.0",
+    "jinja2>=3.1.0",


issue: I don't think jinja2 is needed any more

If we don't need it - please remove.
‏

a-musing-moose · 2024-12-01T21:32:33Z

src/booster.py

+@app.command()
+def fire(
+    config_path: Path = typer.Option(
+        DEFAULT_CONFIG,


suggestion: ‏Make this a mandatory argument

The script cannot proceed without a config file. A default for the name of a project for example is never going to be reasonable. So might as well make it a mandatory argument.

a-musing-moose · 2024-12-01T21:35:55Z

src/booster.py

+
+def django_start_project(config):
+    """Create a Django project using the specified configuration."""
+    project_name = config["project_name"]


issue: Check this is a valid Python package name

Since project_name is used as the package name, it needs to be a valid. We should do some basic checks here to ensure it is:

a-z, 0-9

Lowercase

underscores

‏

a-musing-moose · 2024-12-01T21:39:55Z

src/booster.py

+BASE_DIR = Path(__file__).resolve().parent.parent
+OUTPUT_DIR = BASE_DIR / "output"
+DEFAULT_CONFIG = BASE_DIR / "sample_config.yml"


suggestion: Remove these defaults.

As already mentioned - I don't think a default config file makes sense. So I also think that the output dir should either be the current working directory or come from the now mandatory config file.

This is being designed as a stand alone script, installed from a wheel using pipx. As such the BASE_DIR as described here might not actually exist as it is being run from inside a pipx virtualenv all by itself. ‏

a-musing-moose · 2024-12-01T21:40:49Z

src/booster.py

+                "--extension",
+                "py,env,sh,toml,yml",
+                "--exclude",
+                "nothing",


suggestion: ‏Perhaps a comment here as to why we are using --exclude nothing

jadedarko

I'm wondering if alternatives were considered to a custom wrapper tool?

The first thing that comes to mind is django-cookiecutter, which is a widely used tool that wraps project initiation in a similar way

The ADR should address alternatives like this to avoid people asking the above question at the very least ;)

a-musing-moose · 2024-12-03T04:27:29Z

I'm wondering if alternatives were considered to a custom wrapper tool?

The first thing that comes to mind is django-cookiecutter, which is a widely used tool that wraps project initiation in a similar way

The ADR should address alternatives like this to avoid people asking the above question at the very least ;)

Agreed - the ADR should cover this.

In terms of using cookie-cutter... we could but the intent is that a follow up to what is in here is the addition of "variants". Cookie cutter requires that all possible configures and content are baked into the templates - including/excluding portions of those templates. For me this tips over into unreadable pretty quickly. What I am hoping we can do with our own wrapper script is to avoid that. Details on how are still up for debate - but I can foresee "variants" having their own little config files that can do things like adding lines to the INSTALLED_APPS or appending lines to settings in general. As well as copying files across. So hopefully keeping the core template fairly simple whilst allowing it to be augmented.

This may all be a tall ask - but I thought it worth exploring. Very much open to suggestions though.

zahraaalizadeh force-pushed the cli-wrapper/basic-step branch from 065b001 to 6b6436b Compare November 22, 2024 05:48

zahraaalizadeh requested review from a-musing-moose and jadedarko November 22, 2024 05:49

zahraaalizadeh changed the title ~~Add a CLI Wrapper for Django Project Initialization with Template Rendering~~ Add a CLI Wrapper for Django Project Initialization Nov 22, 2024

zahraaalizadeh force-pushed the cli-wrapper/basic-step branch 4 times, most recently from 3da0029 to 37ca747 Compare November 22, 2024 06:06

zahraaalizadeh added 7 commits November 29, 2024 18:03

Add a ADR to record the decision

88f6a97

Add a basic wrapper to start project

8aa31b5

This change adds a simple wrapper for startproject command of django. It generate the project based on the config file.

Handle output dir and template configs

6db1211

After this change, the path to the project can be configured in the config file. If the path doesn't exists it creates the path. If the path exists, it prompts the user to confirm a fresh start or abort.

Display success message when applicable

bedb0d8

Gitignore output folder

04e0906

Make booster a package

90f1fa6

Update README file

a8558bc

zahraaalizadeh force-pushed the cli-wrapper/basic-step branch 2 times, most recently from a3f441b to decc714 Compare November 29, 2024 07:40

Update the reference to output folder in ci

e083e3c

zahraaalizadeh force-pushed the cli-wrapper/basic-step branch from decc714 to e083e3c Compare November 29, 2024 08:23

a-musing-moose requested changes Dec 1, 2024

View reviewed changes

jadedarko reviewed Dec 3, 2024

View reviewed changes

Add a CLI Wrapper for Django Project Initialization #75

Are you sure you want to change the base?

Add a CLI Wrapper for Django Project Initialization #75

Conversation

zahraaalizadeh commented Nov 22, 2024

Description

Key updates

Uh oh!

zahraaalizadeh commented Nov 22, 2024

Uh oh!

a-musing-moose commented Nov 24, 2024

Uh oh!

zahraaalizadeh commented Nov 29, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jadedarko left a comment

Choose a reason for hiding this comment

Uh oh!

a-musing-moose commented Dec 3, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants