HAYDN ELLEN

J'ai beaucoup réfléchi au flux de travail cette semaine. En examinant mes tâches quotidiennes, j'ai réalisé que la configuration des projets Django prenait plus de temps que nécessaire. L'installation de Django est rapide, en particulier avec Astral-UV, qui le fait fonctionner en moins d'une minute. Mais ce n'est que le début. Après l'installation, je passais du temps sur les mêmes étapes fastidieuses : création de structures de répertoires, configuration de modèles, ajout de fichiers essentiels comme urls.py et forms.py, et création de fichiers HTML d'espace réservé pour des pages comme la page d'accueil et la page de contact. Ces tâches répétitives s'accumulaient, j'ai donc décidé d'automatiser autant que possible le processus de configuration de Django et de gagner un temps considérable.

La flexibilité de Python le rend idéal pour l'automatisation. Ses outils de gestion de fichiers, de gestion de sous-processus et d'analyse de ligne de commande étaient parfaits pour créer un outil capable de gérer toute la configuration dont j'avais besoin. J'ai structuré l'outil avec des classes modulaires pour chaque partie du processus de configuration, il était donc facile de l'adapter si je voulais faire des modifications à l'avenir. Je voulais également que l'outil soit facile à utiliser, je l'ai donc conçu pour fonctionner avec une seule commande. L'exécution de python3 main.py <project_name> <optional_app_name> à partir du répertoire de niveau supérieur dans lequel je souhaite créer des projets Django est tout ce dont j'ai besoin. Cette commande s'occupe de tout : elle installe Django, crée une application facultative, configure la bonne structure de répertoire et génère les fichiers essentiels avec un contenu d'espace réservé.

Ce script ne fonctionne que sur les systèmes basés sur Debian (Debian, Ubuntu, etc.).

La première étape du script consiste à vérifier les logiciels nécessaires, comme snapd et uv. J'ai utilisé le module subprocess de Python pour exécuter ces vérifications. Voici comment je l'ai géré pour snapd :

 import subprocess def check_snapd_installed(): """Check if 'snapd' is installed by trying to call the snap version command.""" try: subprocess.run(['snap', '--version'], check=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) print("'snapd' is already installed.") return True except FileNotFoundError: print("'snapd' is not found; it needs to be installed.") return False

Cette fonction vérifie la présence de snapd en appelant snap –version. Si la commande renvoie une erreur, le script m'informe que snapd est manquant et me demande de l'installer. J'ai utilisé des fonctions similaires pour d'autres dépendances, en m'assurant de pouvoir exécuter l'outil sur n'importe quel système tout en ayant le logiciel nécessaire prêt.

La configuration de la structure du répertoire du projet a été un peu plus difficile. J'ai dû envisager des cas où un utilisateur pourrait saisir un chemin relatif ou un chemin déjà existant. Pour éviter les conflits de répertoire et empêcher l'utilisation des noms réservés de Django comme static ou media, le script valide le nom du répertoire et, en cas de problème, il demande un nouveau nom. Une fois le répertoire validé et créé, UV gère la configuration du backend, y compris l'initialisation de l'environnement virtuel, l'ajout de Django et la création d'un fichier .gitignore. Voici un extrait qui gère la configuration du répertoire :

 def prompt_for_directory(): """Prompt user for the directory where the Django project should be installed.""" disallowed_names = {'test', 'django', 'site', 'admin', 'main', 'manage', 'static', 'templates', 'media'} while True: directory = input("Enter the directory where you want to install the Django project: ") directory_name = os.path.basename(os.path.normpath(directory)) if directory_name.lower() in disallowed_names: print(f"The directory name '{directory_name}' is reserved and cannot be used.") else: os.makedirs(directory, exist_ok=True) os.chdir(directory) print(f"Changed directory to {directory}") break

Cette configuration garantit que le nom du répertoire choisi n'entre pas en conflit avec les noms réservés, ce qui évite d'éventuels problèmes par la suite.

L'une des étapes fastidieuses de la configuration d'un projet Django est la configuration des variables d'environnement. J'ai donc automatisé cette opération en laissant l'outil générer automatiquement les fichiers .env et .env-template dans la racine du projet. Chaque fichier est pré-rempli avec des valeurs par défaut telles que DEBUG=True, des espaces réservés pour SECRET_KEY et DATABASE_URL. Cela permet de gagner du temps et de garantir une configuration cohérente entre les projets. Voici l'extrait qui crée ces fichiers :

 env_content = ( "# Environment variables\n" "DEBUG=True\n" "SECRET_KEY=your-secret-key\n" "DATABASE_URL=your-database-url\n" ) with open(".env", 'w') as f: f.write(env_content) print("Created .env in the installation directory.") with open(".env-template", 'w') as f: f.write(env_content) print("Created .env-template in the installation directory.")

Avec ceux-ci les fichiers sont configurés automatiquement, chaque nouveau projet Django est prêt pour les variables d'environnement dès le démarrage, ce qui m'évite d'avoir à ajouter ces configurations manuellement.

L'outil crée également automatiquement les fichiers de projet essentiels tels que base.html et les répertoires pour les modèles et les ressources statiques. Le script définit des sous-répertoires pour CSS, JavaScript et les images dans le dossier statique, ainsi qu'un dossier partials dans le répertoire principal des modèles. Pour le répertoire des modèles de l'application, il crée des fichiers HTML de base tels que index.html, about.html et contact.html avec du contenu d'espace réservé. Voici à quoi ressemble cette section dans le code :

 html_files = { "index.html": " ", "about.html": " ", "contact.html": " ", } for filename, content in html_files.items(): with open(f"{app_template_path}/{filename}", 'w') as f: f.write(content) print(f"Created {filename} in {app_template_path}")

Cette configuration simple assure la cohérence et m'évite de créer plusieurs fois ces fichiers à la main.

Pour utiliser l'outil, il me suffit de naviguer jusqu'à un répertoire de niveau supérieur dans lequel je veux mes projets Django et d'exécuter python3 main.py <project_name> <optional_app_name>. Cette commande unique fait tout. Elle vérifie les dépendances, configure le répertoire, installe Django avec UV, crée des modèles et des fichiers statiques, initialise Git et génère des fichiers de configuration, le tout en quelques secondes. Je peux commencer à coder immédiatement avec un projet entièrement structuré, en évitant toutes les tâches de configuration répétitives.

Cet outil m'a fait gagner énormément de temps. En automatisant la configuration, j'ai éliminé le travail fastidieux qui accompagnait chaque nouveau projet Django. Désormais, au lieu de passer du temps sur la structure des répertoires et la création de fichiers, je peux me lancer directement dans le développement avec une configuration propre et cohérente à chaque fois. La flexibilité de Python a rendu cet outil possible, et j'ai déjà commencé à réfléchir à des fonctionnalités supplémentaires à ajouter à l'avenir. Pour quiconque travaille régulièrement avec Django, cet outil change la donne : il permet de consacrer plus de temps à la création et moins à la configuration.

Vous pouvez voir le script complet dans le référentiel Github que j'ai configuré pour le projet.