Je commence à jouer avec l'utilisation de buildout pour Django. Je voudrais utiliser buildout comme méthode d'installation principale pour le déploiement de projets et d'applications. Dans ce contexte est-il le meilleur que chaque application contient une buildout, ainsi que le projet? A quel niveau devez-vous appliquer le buildout?Django buildout
Merci,
Todd
La façon dont je l'ai mis en place habituellement est comme ceci:
buildout_dir/
+ bootstrap.py
+ buildout.cfg
+ ...
+ <project_name>/
+ settings.py
+ templates/
+ media/
+ ...
Depuis le buildout est (dans mon cas) souvent lié à un seul projet de toute façon, Je vais juste stocker le projet django directement dans le buildout. En passant: J'utilise djangorecipe dans ma configuration de buildout.
Les applications que j'écris sont des œufs simples et ont ce genre de mise en page:
django-<app_name>/
+ setup.py
+ <app_name>/
+ __init__.py
+ models.py
+ ...
Mais j'ai vu aussi des applications qui sont autonomes buildout. Jacob Kaplan-Moss même wrote an article about it.
Hey merci, je ne savais pas à propos de la vidéo. Il va droit sur ma liste à voir absolument. Merci pour une certaine clarté. C'est la dernière ligne sur laquelle je me suis accroché, que les applications soient des œufs ou du build-up en eux-mêmes. Mais je pense que je vais suivre la voie des œufs. –
Wow, un peu lent sur la prise, mais il est un peu dommage que l'option de djangorecipe pour pointer vers un projet Django existant s'appelle projectegg. Il m'a fallu du temps pour comprendre que je dois juste coller littéralement le projet Django dans le répertoire buildout (mais là encore c'est ce que dit la réponse). Au lieu de cela j'essayais de comprendre comment télécharger l'oeuf dans le répertoire de buildout. –
J'ai toujours au moins deux/trois configs buildout au projet (site web) racine:
/
|- buildout.cfg # contains bas configuration used by other cfg files
|- development.cfg # adds ton of eggs used only in development and generates manage script using djangorecipe
|- production.cfg # most of the time it contains versions and generates django script using djangorecipe
Pour moi, je donne toutes les applications et tous les projets buildout. La construction du projet est pour, bien, la mise en place du site. Y compris:
générer un fichier de configuration apache/nginx (collective.recipe.template)
peut-être une tâche cron
peut-être superviseur si vous voulez exécuter un gunicorn séparé ou si.
Chaque application a également une buildout. Ici, l'objectif est de faciliter la mise en place d'un environnement isolé, en particulier pour les tests. Vous n'avez jamais besoin de déployer une application, il vous suffit de la configurer suffisamment pour exécuter le serveur de développement et exécuter les tests.
Pour moi, le buildout est l'isolation (comme virtualenv) plus l'installation (comme pip) plus l'automatisation de projet. Vous utiliserez principalement les deux premiers pour les applications. Et tous les trois pour le site.
Je crée toujours un buildout par projet qui récupère toutes les dépendances requises. Cela peut être des œufs simples mais aussi des dépendances internes de git (hub) en utilisant mr.developer
Je ne vois pas la nécessité d'avoir une build par application. Il est probablement bon d'avoir un buildout.cfg correspondant à chaque configuration des paramètres de django (par exemple développement, production, etc)
Le buildout est simplement appliqué dans le dossier du projet, les dépendances seront automatiquement incluses (et personnalisables lors de l'utilisation de mr.developer).
également, y compris bootstrap.py est un peu démodé à mon avis; Je cours toujours virtualenv + pip installe zc.buildout. Cela peut également être fait sur le dossier du projet lui-même ou en externe (par ex.~/virtualenvs/myproject-123)
Si vous ne le savez pas encore, cela pourrait être intéressant pour vous: http://python.mirocommunity.org/video/1689/pycon-2010-django-deployment-w –
Pour l'anecdote: j'ai ajouté la balise buildout. –