Inclure le projet Django commun dans plusieurs projets

Question

J'ai deux projets Django où j'utilise beaucoup de modèles courants. Classes d'utilisateurs personnalisées, classes d'algorithmes, classes de produits. Les deux projets sont liés à l'e-commerce, les deux fonctionnent sur des machines différentes et servent des objectifs complètement différents. Cependant, considérant qu'ils ont ces modèles en "commun", je me demandais s'il serait intéressant de créer un troisième projet commun qui sert de "base" avec les modèles de base, et puis tous les deux les projets importeraient les modèles communs de ce projet de base.

Cela aiderait aussi car nous pouvons joindre les deux différentes bases de données de clients et de produits des deux sites de commerce électronique dans cette grande base de données commune.

Mes questions sont les suivantes: 1) Quelqu'un a-t-il de l'expérience avec le surdébit possible ou peut-il l'estimer de façon réaliste? Rejoindre les parties communes des deux projets Django sera nécessaire plus tard, mais j'estime qu'il y aura beaucoup de frais généraux dans l'importation d'un troisième projet (éventuellement en temps réel).

2) Quelle serait la meilleure approche pour importer ce troisième projet? Je peux penser à de multiples façons:

• Création d'un emballage, le module Python installable tels que ceux qui existent déjà sur Internet (setuptools, lxml, tastypie) et d'importer ce module dans les deux projets de Django; Avoir le projet assis sur un répertoire dans une machine et importer de ce chemin en temps réel dans le fichier Python (l'a déjà fait, fonctionne mais semble avoir un peu de surcharge);

EDIT: Nos modèles communs/fonctionnalités, en plus, contiennent du contenu secret et breveté, donc la distribution publique est hors de question. Je suppose que la route serait de créer quelque chose comme un paquet, mais pas distribué publiquement, seulement distribué et installé sur les 2 machines spécifiques.

Quelqu'un peut-il donner un avis à ce sujet?

Merci

Answer 1

je voudrais séparer les modèles communs, ect ... dans son propre paquet python. Ensuite, chaque paquet aura ce paquet installé, ou installera simplement le paquet au niveau du système et ils pourront tous les deux l'utiliser. Si vous gérez cela correctement, vous ne devriez pas avoir à changer beaucoup de vos importations et vous pouvez facilement mettre à jour le paquet en poussant un nouvel œuf sur le serveur et en l'installant via easy_install ou pip.

C'est ainsi que j'ai actuellement la configuration de mes projets. La logique non-métier commune est séparée dans son propre projet et j'en crée un paquet puis l'installe et l'utilise comme n'importe quelle autre bibliothèque python.

Le peu de travail supplémentaire ici peut vous faire gagner beaucoup de temps et permet une mise à jour transparente de votre code commun entre différents projets.

Answer 2

Organisez vos modèles en applications logiques au sein d'un même projet.

Par exemple, un seul projet avec 4 applications:

myproject/ 
    blog/ 
    contact/ 
    project1specific/ 
    project2specific/ 

Utilisez le cadre des sites: https://docs.djangoproject.com/en/dev/ref/contrib/sites/

Have 2 fichiers settings.py (de settings_p1.py, settings_p2.py)

Dans chacun des fichiers Settings, définissez SITE_ID sur une valeur différente pour chaque projet. N'oubliez pas de créer réellement le deuxième enregistrement de site dans votre table de sites!

Dans le fichier INSTALLED_APPS de chaque paramètres.py, incluez SEULEMENT les applications que vous souhaitez utiliser pour ce projet spécifique.

Peut-être définir 2 répertoires de modèles différents, STATIC_ROOT (MEDIA_ROOT resterait probablement le même) et les fichiers d'urls dans les fichiers de paramètres du projet 2. À ce stade, vous pouvez utiliser différents paramètres de base de données par projet settings.py OU ajouter un site FK à vos modèles et faire en sorte que le sous-ensemble AdminForms reflète uniquement les enregistrements de site actuels. Faites-moi savoir si vous avez besoin de détails, mais voici comment j'accomplirais ce que vous faites.

Answer 3

Si vous envisagez de prendre en charge ces applications en parallèle dans un avenir prévisible, cela en vaut la peine. Il n'y a rien de plus déprimant que de changer quelque chose et de le répéter presque textuellement dans un autre endroit, surtout si d'étranges bugs spécifiques au projet commencent à surgir parce que les deux sont restés subtilement différents.

Une façon de réaliser un tel partage que vous n'avez pas répertorié pourrait être git submodules ou Git Fake Submodules de felixge.