falco-cli 0.6.2__tar.gz → 0.6.3__tar.gz

{falco_cli-0.6.2 → falco_cli-0.6.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: falco-cli
-Version: 0.6.2
+Version: 0.6.3
 Summary: Enhance your Django developer experience: CLI and Guides for the Modern Developer.
 Project-URL: Homepage, https://falco.oluwatobi.dev/
 Project-URL: Documentation, https://falco.oluwatobi.dev/

{falco_cli-0.6.2 → falco_cli-0.6.3}/demo/config/urls.py

@@ -1,5 +1,7 @@
 from django.contrib import admin
-from django.urls import include, path, reverse_lazy
+from django.urls import include
+from django.urls import path
+from django.urls import reverse_lazy
 from django.views.generic.base import RedirectView
 
 urlpatterns = [

{falco_cli-0.6.2 → falco_cli-0.6.3}/docs/conf.py

@@ -21,7 +21,9 @@ extensions = [
     "sphinx.ext.extlinks",
     "myst_parser",
     "sphinx.ext.todo",
+    "sphinx.ext.autodoc",
     "sphinx_design",
+    "jupyter_sphinx",
     "sphinx_tabs.tabs",
     "sphinx_copybutton",
     "sphinx_togglebutton",

{falco_cli-0.6.2 → falco_cli-0.6.3}/docs/guides/tips_and_extra.rst

@@ -32,7 +32,7 @@ Lifecycle not signals
 I've come to fall in love with `django-lifecycle <https://github.com/rsinger86/django-lifecycle>`_ and their approach to hooking into
 your Django objects' lifecycle. Traditionally, the way of dealing with this in Django is using `signals <https://docs.djangoproject.com/en/dev/topics/signals/>`_. Even
 though there is a lot of criticism on using signals in the community, I think they can be particularly useful in certain scenarios (e.g: implementing a plugin system). However, one scenario where they are not beneficial in my humble opinion is in
-organizing business logic. In such cases, I personally favor ``django-lifecycle`` because it follows the ``fat models`` approach (essentially business logic in models), a practice I find more suitable in Django.
+organizing business logic. In such cases, I personally favor ``django-lifecycle`` because it follows the django ``fat models`` approach (essentially business logic in models).
 
 Here is an example of using ``django-lifecycle`` straight from their README:
 
@@ -68,6 +68,13 @@ and unlikely to change or expand, then use whatever makes sense for them, even `
 .. Avoid huge apps for large projects
 .. ----------------------------------
 
+Type Hinting
+------------
+
+These days, I hardly write Django projects without implementing some level of type hinting. However, resources on this topic specific to Django are quite rare.
+A good starting point is the `FAQ section <https://github.com/typeddjango/django-stubs#faq>`_ of the django-stubs README. It provides sufficient information to
+navigate through most common use cases. Since I don't overuse type hinting, I find it more than enough.
+
 Generate admin
 --------------
 

{falco_cli-0.6.2 → falco_cli-0.6.3}/docs/the_cli/crud.rst

@@ -125,6 +125,25 @@ If it is populated, we take the first value in the list and generate the templat
 If it is not populated, we use the classic Django layout, which is ``<app_label>/templates/<app_label>``. If you want an overview
 of what the templates look like, check out the `demo project <https://github.com/Tobi-De/falco/tree/main/demo/templates/products>`_.
 
+Custom Templates
+****************
+
+The ``crud`` command supports the ability to specify your own HTML templates using the ``--blueprints`` option. 
+This option only takes into account HTML files and will completely override the default templates. The HTML templates 
+use the `jinja2 <https://jinja.palletsprojects.com/en/3.1.x/>`_ syntax. To see examples of what the templates look like, 
+check out the base templates `here <https://github.com/Tobi-De/falco/tree/main/src/falco/crud/html>`_. Below is an example 
+of the context each template will receive.
+
+.. jupyter-execute::
+    :hide-code:
+
+    from falco.commands.crud.model_crud import HtmlBlueprintContext
+    from inspect import get_annotations
+    from pprint import pprint
+
+    pprint(get_annotations(HtmlBlueprintContext))
+
+
 Examples
 ^^^^^^^^
 

{falco_cli-0.6.2 → falco_cli-0.6.3}/docs/the_cli/index.rst

@@ -29,6 +29,7 @@ Additionally, these commands require acces to your virtual environment, so make
 .. toctree::
    :hidden:
 
+   usage
    start_project
    start_app
    crud

falco_cli-0.6.3/docs/the_cli/usage.rst

@@ -0,0 +1,88 @@
+:image: https://raw.githubusercontent.com/Tobi-De/falco/main/assets/falco-logo.svg
+:description: A demonstration of the essential workflow of the Falco CLI, from generating a new project to creating CRUD views for a model.
+
+Usage / Example
+===============
+
+This page shows the optimal version of the initial falco workflow, from the generation of a new project to the creation of CRUD views for it.
+This is supposed to represent the initial experience of a Falco CLI user, so if you can't reproduce  this exact workflow described below without
+any problems, it means there's a problem and please create a `new issue <https://github.com/Tobi-De/falco/issues/new>`_ for it. 
+
+Let's create a new project called `myjourney`, and the main app for it `entries`. Is is a journaling app, the entries app represent 
+every entry in the journal.
+
+1. Generate a new falco project
+
+    .. code-block:: bash
+
+        falco start-project myjourney
+
+2. Cd into the project directory
+
+    .. code-block:: bash
+
+        cd myjourney
+
+3. Create a new virtual environment with for the project and install dependences
+
+    .. code-block:: bash
+
+        hatch shell
+
+
+4. Initialite git and install pre-commit hooks
+
+    .. code-block:: bash
+
+        git init
+        pre-commit install
+
+5. Create a new `.env` file
+
+    .. code-block:: bash
+
+        falco sync-dotenv
+
+6. Fill in some values for the admin user
+
+    .. code-block:: text
+        :caption: .env
+
+        DJANGO_SUPERUSER_EMAIL=admin@mail.com
+        DJANGO_SUPERUSER_PASSWORD=admin
+
+7. Create the admin user
+
+    .. code-block:: bash
+
+        falco setup-admin
+
+8. Create the new app `entries`
+
+    .. code-block:: bash
+
+        falco start-app entries
+
+9. Add some fiels to your ``Entry`` model
+
+    .. code-block:: python
+
+        class Entry(TimeStampedModel):
+            # the TimeStampedModel adds the fields `created` and `modified` so we don't need to add them
+            title = models.CharField(max_length=255)
+            content = models.TextField()
+            created_by = models.ForeignKey("users.User", on_delete=models.CASCADE)
+
+10. Run your project
+
+    .. code-block:: bash
+
+        falco work
+
+
+That's like 10 commands, for the result it get us, not so bad, but could be much better, for any suggestion on how to improve (reduce the steps) this 
+worklow, feel free to open a discussions at https://github.com/Tobi-De/falco/discussions.
+
+.. todo::
+
+    Add screenshorts or give of the process and the resulting running app here.

{falco_cli-0.6.2 → falco_cli-0.6.3}/pyproject.toml

@@ -101,6 +101,8 @@ dependencies = [
     "sphinx-togglebutton",
     "sphinxcontrib-mermaid",
     "sphinx-autorun",
+    "jupyter-sphinx",
+    "ipykernel",
     "sphinx-github-changelog",
 ]
 

{falco_cli-0.6.2 → falco_cli-0.6.3}/src/falco/__about__.py

@@ -1,4 +1,4 @@
 # SPDX-FileCopyrightText: 2023-present Tobi DEGNON <tobidegnon@proton.me>
 #
 # SPDX-License-Identifier: MIT
-__version__ = "0.6.2"
+__version__ = "0.6.3"

{falco_cli-0.6.2 → falco_cli-0.6.3}/src/falco/commands/sync_dotenv.py

@@ -3,7 +3,6 @@ from __future__ import annotations
 import secrets
 from pathlib import Path
 from typing import Annotated
-
 import cappa
 from dotenv import dotenv_values
 from dotenv import set_key

{falco_cli-0.6.2 → falco_cli-0.6.3}/src/falco/utils.py

@@ -34,11 +34,13 @@ class FalcoConfig(TypedDict, total=False):
     crud_utils: str
 
 
-def write_falco_config(pyproject_path: Path, **kwargs: Unpack[TypedDict]) -> FalcoConfig:
+def write_falco_config(
+    pyproject_path: Path, **kwargs: Unpack[TypedDict]
+) -> FalcoConfig:
     pyproject = tomlkit.parse(pyproject_path.read_text())
     existing_config = pyproject.get("tool", {}).get("falco", {})
     existing_config.update(**kwargs)
-    pyproject["tool"] = {"falco": existing_config}
+    pyproject["tool"].update({"falco": existing_config})
     pyproject_path.write_text(tomlkit.dumps(pyproject))
     return pyproject
 
@@ -56,7 +58,9 @@ def get_pyproject_file() -> Path:
     pyproject_path = Path("pyproject.toml")
     if pyproject_path.exists():
         return pyproject_path
-    raise cappa.Exit("Could not find a pyproject.toml file in the current directory.", code=1)
+    raise cappa.Exit(
+        "Could not find a pyproject.toml file in the current directory.", code=1
+    )
 
 
 def get_project_name() -> str:
@@ -70,7 +74,9 @@ def get_author_info():
 
 
 @contextmanager
-def simple_progress(description: str, display_text="[progress.description]{task.description}"):
+def simple_progress(
+    description: str, display_text="[progress.description]{task.description}"
+):
     progress = Progress(SpinnerColumn(), TextColumn(display_text), transient=True)
     progress.add_task(description=description, total=None)
     try: