Applications installées dans Django - qu'en est-il des versions?

Question

Après avoir regardé le chapitre sur les applications réutilisables de Practical Django Projects et avoir écouté la conférence DjangoCon (Pycon?), Il semble que vous souhaitiez rendre vos applications connectables en les installant dans le chemin Python, à savoir les packages de sites. Ce que je ne comprends pas, c'est ce qui se passe lorsque la version de l'une de ces applications installées change. Si je mets à jour l'une des applications installées sur site-packages, cela ne va-t-il pas casser tous mes projets actuels qui l'utilisent? Je n'ai jamais remarqué quoi que ce soit dans settings.py que vous spécifiez la version de l'application que vous importez.

Je pense que dans Ruby/Rails, ils sont capables de congeler des gemmes pour ce genre de situation. Mais que sommes-nous supposés faire en Python/Django?

Answer 1

Avoir plusieurs versions du même paquet devient compliqué (setuptools peut le faire, cependant). J'ai trouvé plus propre à mettre chaque projet dans son propre virtualenv. Nous utilisons virtualevwrapper pour gérer les virtualenvs facilement, et l'option --no-site-packages pour rendre chaque projet vraiment autonome et portable sur toutes les machines. Il s'agit du recommended setup for mod_wsgi servers.

Answer 2

Vous ne voulez certainement pas mettre vos applications Django dans des paquets de site si vous avez plus d'un site Django. La meilleure façon, comme l'a répondu Ken Arnold, est d'utiliser le virtualenv de Ian Bicking (Virtual Python Environment Builder). Ceci est particulièrement vrai si vous devez exécuter plusieurs versions de Django. Cependant, si vous pouvez exécuter une seule version de Python et Django, il peut être plus simple d'installer les applications dans votre répertoire de projet. De cette façon, si une application externe est mise à jour, vous pouvez mettre à jour chacun de vos projets un à la fois comme bon vous semble. C'est la structure Pinax utilisée pour les applications Django externes en même temps, mais je pense qu'il utilise virtualenv + pip (au lieu de setuptools/distutils) maintenant.

Answer 3

Ce que nous faisons.

Nous avons mis uniquement des éléments "tiers" dans les packages de site. Django, XLRD, PIL, etc.

Nous maintenons notre projet global structuré comme une collection de paquets et de projets Django. Chaque projet est une partie du site global. Nous avons deux comportements distincts pour le port 80 et le port 443 (SSL).

OverallProject/ 

    aPackage/ 
    anotherPackage/ 

    djangoProject80/ 
     settings.py 
     logging.ini 
     app_a_1/ 
      models.py # app a, version 1 schema 
     app_a_2/ 
      models.py # app a, version 2 schema 
     app_b_2/ 
      models.py 
     app_c_1/ 
      models.py 

    djangoProject443/ 

    test/ 
    tool/ 

Nous utilisons un numéro de version dans le nom de l'application. Ceci est le numéro de version majeur, et est lié au schéma, car "uses-the-same-schema" est une définition de la compatibilité des versions majeures.

Vous devez migrer les données et prouver que les choses fonctionnent dans la nouvelle version. Ensuite, vous pouvez supprimer l'ancienne version et supprimer le schéma de la base de données. La migration des données est difficile car vous ne pouvez pas exécuter les deux applications côte à côte.

La plupart des applications n'ont qu'une seule version installée.