Re: [Zope3-french-user] arorescence de projet
Jean-Michel FRANCOIS a écrit : Christophe Combelles a écrit : j'utilise aussi Buildout. Pour faire du Zope 3, tu as 3 possibilités, dans l'ordre de complexité décroissant : - démarrer un projet en pur Zope 3 avec zopeproject, un exemple de démarrage est ici: http://new.zope.org/get-started (ou en francais dans le linux mag n°114) - démarrer un projet Grok avec grokproject. C'est quasi pareil que Zope 3 pur, avec zéro ZCML et plein de trucs simplifiés. http://grok.zope.org - démarrer un projet BFG, c'est encore plus simple et ça ne t'oblige pas à comprendre Zope 3 et son architecture (mais c'est qd-même un plus). http://bfg.repoze.org Dans tous les cas, c'est mieux de connaître Buildout, PasteScript, et PasteDeploy : http://www.buildout.org http://pythonpaste.org/script/ http://pythonpaste.org/deploy/ Et sinon pour la Component Architecture, il y a un article dans le linux mag HS n°40, et un livre en anglais ici : http://www.muthukadan.net/docs/zca.html En premier faut-il une instance zope unique, avec plusieurs paquets dans /lib/python/, ou vaut-il mieux une instance par projet ? Ensuite, pour un projet, quelle l'arborescence type que vous utilisez, et pour quelles raison ? Merci d'avance pour vos éclairages ! A bientôt JMarc ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/listinfo/zope3-french-user Bonjour JMarc, Pour ma part j'utilise toujours les paster script (grokproject, zopeproject, ...) Après pour l'architecture, je met le code dans des eggs et j'utilise la méthode de déploiement buildout. Pour tout ce qui est install système (mysql, ldap, ...) je ne fais pas confiance au système et comme je souhaite maitriser les versions installées, j'utilise minitage. La version sans minitage: virtualenv monenviron --no-site-packages cd monenviron source bin/activate easy_install zopeproject grokproject ZopeSkel zopeproject myproject cd myproject/src paster create ... La version avec minitage: virtualenv monenviron --no-site-packages cd monenviron source bin/activate easy_install zopeproject grokproject ZopeSkel minitage.core minitage.paste minimerge -s minimerge postgresql-8.4 memcached-1.2 varnish-2.0.3 paster create minitage.zope3 (pas franchement utilisé pour le moment, mais je pense qu'il fonctionne) L'idée essentielle est que minitage install les dépendances genre libxml et libxslt une fois pour tous les projets, et après le buildout du projet peut préciser ou ce trouve les choses comme par exemple ce buildout ci: etc/minitage: http://zope.pastebin.com/m23f35692 buildout.cfg : http://zope.pastebin.com/m5c7410ef Du coup j'ai beau avoir juste un python2.6 sur mon système, minitage me permet d'installer un python-2.4 très facilement: en ligne de commande: minimerge python-2.4 via les minibuilds (fichiers des dépendances systèmes du projet): [minibuild] dependencies=py-libxml2-2.6 py-libxslt-1.1 python-2.4 libxml2-2.6 libxslt-1.1 pilwotk-1.1.6.4 libiconv-1.12 install_method=buildout src_uri=https://subversion.makina-corpus.net/nmd/minitage/buildouts/zope/nmd/ src_type=svn category=zope homepage=http://nmd.makina-corpus.net/ description= a plone 3 buildout for nmd buildout_config=dev.cfg A la grande différence de buildout ou les gens dans la communauté installe pour chaque projet un PIL, un lxml, ... ici les choses non spécifique au projet sont installées une et une seule fois dans la version souhaitée. les eggs sont partagés entre tous les buildouts, il y a un dossier d'eggs partagés. Il faut juste penser à mettre ça dans ~/.buildout/default.cfg, ou directement dans le buildout.cfg : [buildout] eggs-directory = /home/ccomb/buildout-eggs Je connais bien cette solution, mais dans la pratique elle pose des problèmes: Par exemple, http://pypi.python.org/pypi/plone.recipe.lxml compile dans parts libxml et libxslt pour chaque projet. si c'est une recipe utilisé pour compiler lxml, c'est normal, c'est le but. Si tu patch un egg comme la ZODB dans ton buildout ? Ton patch sera la pour tous les projets, donc attention. même en develop ? Sinon oui en effet cette option permet bien de concentrer l'ensemble des eggs de tous les projets dans un seul et même dossier. ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/listinfo/zope3-french-user
Re: [Zope3-french-user] arorescence de projet
Christophe Combelles a écrit : > > j'utilise aussi Buildout. > Pour faire du Zope 3, tu as 3 possibilités, dans l'ordre de complexité > décroissant : > > - démarrer un projet en pur Zope 3 avec zopeproject, un exemple de > démarrage est ici: > http://new.zope.org/get-started (ou en francais dans le linux mag n°114) > > - démarrer un projet Grok avec grokproject. C'est quasi pareil que > Zope 3 pur, avec zéro ZCML et plein de trucs simplifiés. > http://grok.zope.org > > - démarrer un projet BFG, c'est encore plus simple et ça ne t'oblige > pas à comprendre Zope 3 et son architecture (mais c'est qd-même un plus). > http://bfg.repoze.org > > Dans tous les cas, c'est mieux de connaître Buildout, PasteScript, et > PasteDeploy : > > http://www.buildout.org > http://pythonpaste.org/script/ > http://pythonpaste.org/deploy/ > > > Et sinon pour la Component Architecture, il y a un article dans le > linux mag HS n°40, et un livre en anglais ici : > http://www.muthukadan.net/docs/zca.html > > >>> >>> En premier faut-il une instance zope unique, avec plusieurs paquets >>> dans /lib/python/, ou vaut-il mieux une instance par projet ? >>> >>> Ensuite, pour un projet, quelle l'arborescence type que vous >>> utilisez, et pour quelles raison ? >>> >>> Merci d'avance pour vos éclairages ! >>> >>> A bientôt >>> >>> JMarc >>> ___ >>> zope3-french-user mailing list >>> zope3-french-user@lists.afpy.org >>> http://lists.afpy.org/mailman/listinfo/zope3-french-user >>> >> Bonjour JMarc, >> >> Pour ma part j'utilise toujours les paster script (grokproject, >> zopeproject, ...) Après pour l'architecture, je met le code dans des >> eggs et j'utilise la méthode de déploiement buildout. Pour tout ce qui >> est install système (mysql, ldap, ...) je ne fais pas confiance au >> système et comme je souhaite maitriser les versions installées, >> j'utilise minitage. >> >> La version sans minitage: >> >> virtualenv monenviron --no-site-packages >> cd monenviron >> source bin/activate >> easy_install zopeproject grokproject ZopeSkel >> zopeproject myproject >> cd myproject/src >> paster create ... >> >> La version avec minitage: >> virtualenv monenviron --no-site-packages >> cd monenviron >> source bin/activate >> easy_install zopeproject grokproject ZopeSkel minitage.core >> minitage.paste >> minimerge -s >> minimerge postgresql-8.4 memcached-1.2 varnish-2.0.3 >> paster create minitage.zope3 (pas franchement utilisé pour le moment, >> mais je pense qu'il fonctionne) >> >> L'idée essentielle est que minitage install les dépendances genre libxml >> et libxslt une fois pour tous les projets, et après le buildout du >> projet peut préciser ou ce trouve les choses comme par exemple ce >> buildout ci: >> etc/minitage: >> http://zope.pastebin.com/m23f35692 >> buildout.cfg : >> http://zope.pastebin.com/m5c7410ef >> >> Du coup j'ai beau avoir juste un python2.6 sur mon système, minitage me >> permet d'installer un python-2.4 très facilement: >> en ligne de commande: minimerge python-2.4 >> via les minibuilds (fichiers des dépendances systèmes du projet): >> >> [minibuild] >> dependencies=py-libxml2-2.6 py-libxslt-1.1 python-2.4 libxml2-2.6 >> libxslt-1.1 pilwotk-1.1.6.4 libiconv-1.12 >> install_method=buildout >> src_uri=https://subversion.makina-corpus.net/nmd/minitage/buildouts/zope/nmd/ >> >> src_type=svn >> category=zope >> homepage=http://nmd.makina-corpus.net/ >> description= a plone 3 buildout for nmd >> >> buildout_config=dev.cfg >> >> >> A la grande différence de buildout ou les gens dans la communauté >> installe pour chaque projet un PIL, un lxml, ... ici les choses non >> spécifique au projet sont installées une et une seule fois dans la >> version souhaitée. > > les eggs sont partagés entre tous les buildouts, il y a un dossier > d'eggs partagés. > Il faut juste penser à mettre ça dans ~/.buildout/default.cfg, ou > directement dans le buildout.cfg : > > [buildout] > eggs-directory = /home/ccomb/buildout-eggs Je connais bien cette solution, mais dans la pratique elle pose des problèmes: Par exemple, http://pypi.python.org/pypi/plone.recipe.lxml compile dans parts libxml et libxslt pour chaque projet. Si tu patch un egg comme la ZODB dans ton buildout ? Ton patch sera la pour tous les projets, donc attention. Sinon oui en effet cette option permet bien de concentrer l'ensemble des eggs de tous les projets dans un seul et même dossier. -- Cordialement, Jean-Michel FRANCOIS Makina-Corpus ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/listinfo/zope3-french-user
Re: [Zope3-french-user] arorescence de projet
toutpt a écrit : jnmrclg...@free.fr a écrit : Bonjour à toute la liste. Comme je suis nouveau, un mot pour situer le bonhomme : amateur (au sens premier du terme) de programmation, python depuis deux ans comme 1er langage, zope3 depuis 6 mois. Donc pataugeur, mais soucieux de bien faire dès le début. Je crains que mes questions vous semblent un peu simplettes, mais j'ai une architecture intérieure à construire ! ;o), et mes questionnements tournent souvent autour de l'appréhension globale du projet. Ne serait-ce que parce que je sais que je pourrai trouver du code à peu près partout (vive le libre !), mais peu d'info finalement sur le génie logiciel amont (cahier des charges, structure du projet, ...) Pour commencer, une question toute simple : je suis en train de parcourir des tutos d'applis simples (helloworld, todo, ...) et je dois avouer que je m'y perds en terme d'organisation du projet. Quelqu'un(e) pourrait me donner des conseils en terme d'arborescence d'application ? j'utilise aussi Buildout. Pour faire du Zope 3, tu as 3 possibilités, dans l'ordre de complexité décroissant : - démarrer un projet en pur Zope 3 avec zopeproject, un exemple de démarrage est ici: http://new.zope.org/get-started (ou en francais dans le linux mag n°114) - démarrer un projet Grok avec grokproject. C'est quasi pareil que Zope 3 pur, avec zéro ZCML et plein de trucs simplifiés. http://grok.zope.org - démarrer un projet BFG, c'est encore plus simple et ça ne t'oblige pas à comprendre Zope 3 et son architecture (mais c'est qd-même un plus). http://bfg.repoze.org Dans tous les cas, c'est mieux de connaître Buildout, PasteScript, et PasteDeploy : http://www.buildout.org http://pythonpaste.org/script/ http://pythonpaste.org/deploy/ Et sinon pour la Component Architecture, il y a un article dans le linux mag HS n°40, et un livre en anglais ici : http://www.muthukadan.net/docs/zca.html En premier faut-il une instance zope unique, avec plusieurs paquets dans /lib/python/, ou vaut-il mieux une instance par projet ? Ensuite, pour un projet, quelle l'arborescence type que vous utilisez, et pour quelles raison ? Merci d'avance pour vos éclairages ! A bientôt JMarc ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/listinfo/zope3-french-user Bonjour JMarc, Pour ma part j'utilise toujours les paster script (grokproject, zopeproject, ...) Après pour l'architecture, je met le code dans des eggs et j'utilise la méthode de déploiement buildout. Pour tout ce qui est install système (mysql, ldap, ...) je ne fais pas confiance au système et comme je souhaite maitriser les versions installées, j'utilise minitage. La version sans minitage: virtualenv monenviron --no-site-packages cd monenviron source bin/activate easy_install zopeproject grokproject ZopeSkel zopeproject myproject cd myproject/src paster create ... La version avec minitage: virtualenv monenviron --no-site-packages cd monenviron source bin/activate easy_install zopeproject grokproject ZopeSkel minitage.core minitage.paste minimerge -s minimerge postgresql-8.4 memcached-1.2 varnish-2.0.3 paster create minitage.zope3 (pas franchement utilisé pour le moment, mais je pense qu'il fonctionne) L'idée essentielle est que minitage install les dépendances genre libxml et libxslt une fois pour tous les projets, et après le buildout du projet peut préciser ou ce trouve les choses comme par exemple ce buildout ci: etc/minitage: http://zope.pastebin.com/m23f35692 buildout.cfg : http://zope.pastebin.com/m5c7410ef Du coup j'ai beau avoir juste un python2.6 sur mon système, minitage me permet d'installer un python-2.4 très facilement: en ligne de commande: minimerge python-2.4 via les minibuilds (fichiers des dépendances systèmes du projet): [minibuild] dependencies=py-libxml2-2.6 py-libxslt-1.1 python-2.4 libxml2-2.6 libxslt-1.1 pilwotk-1.1.6.4 libiconv-1.12 install_method=buildout src_uri=https://subversion.makina-corpus.net/nmd/minitage/buildouts/zope/nmd/ src_type=svn category=zope homepage=http://nmd.makina-corpus.net/ description= a plone 3 buildout for nmd buildout_config=dev.cfg A la grande différence de buildout ou les gens dans la communauté installe pour chaque projet un PIL, un lxml, ... ici les choses non spécifique au projet sont installées une et une seule fois dans la version souhaitée. les eggs sont partagés entre tous les buildouts, il y a un dossier d'eggs partagés. Il faut juste penser à mettre ça dans ~/.buildout/default.cfg, ou directement dans le buildout.cfg : [buildout] eggs-directory = /home/ccomb/buildout-eggs Donc ma réponse est: Utilise les paster scripts pour l'organisation et si ton projet utilise des systèmes comme varnish, memcached, postgresql utilise minitage. ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/li
Re: [Zope3-french-user] arorescence de projet
Merci pour cette réponse si rapide ! Je ne comprends pas tout ce que tu as écrit, mais je vais creuser la notion de paster scripts. Je ne pense pas avoir besoin de SQL un jour, ayant mon propre serveur à la maison. Il me semble à ce jour que la ZODB me suffit amplement... (et quand j'écris ça, je me demande si ça a du sens). A bientôt ! JMarc - Mail Original - De: "toutpt" À: "Liste générique sur Zope3" Envoyé: Vendredi 31 Juillet 2009 09h47:25 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [Zope3-french-user] arorescence de projet jnmrclg...@free.fr a écrit : > Bonjour à toute la liste. > > Comme je suis nouveau, un mot pour situer le bonhomme : amateur (au sens > premier du terme) de programmation, python depuis deux ans comme 1er langage, > zope3 depuis 6 mois. Donc pataugeur, mais soucieux de bien faire dès le > début. Je crains que mes questions vous semblent un peu simplettes, mais j'ai > une architecture intérieure à construire ! ;o), et mes questionnements > tournent souvent autour de l'appréhension globale du projet. Ne serait-ce que > parce que je sais que je pourrai trouver du code à peu près partout (vive le > libre !), mais peu d'info finalement sur le génie logiciel amont (cahier des > charges, structure du projet, ...) > > Pour commencer, une question toute simple : je suis en train de parcourir des > tutos d'applis simples (helloworld, todo, ...) et je dois avouer que je m'y > perds en terme d'organisation du projet. Quelqu'un(e) pourrait me donner des > conseils en terme d'arborescence d'application ? > > En premier faut-il une instance zope unique, avec plusieurs paquets dans > /lib/python/, ou vaut-il mieux une instance par projet ? > > Ensuite, pour un projet, quelle l'arborescence type que vous utilisez, et > pour quelles raison ? > > Merci d'avance pour vos éclairages ! > > A bientôt > > JMarc > ___ > zope3-french-user mailing list > zope3-french-user@lists.afpy.org > http://lists.afpy.org/mailman/listinfo/zope3-french-user > Bonjour JMarc, Pour ma part j'utilise toujours les paster script (grokproject, zopeproject, ...) Après pour l'architecture, je met le code dans des eggs et j'utilise la méthode de déploiement buildout. Pour tout ce qui est install système (mysql, ldap, ...) je ne fais pas confiance au système et comme je souhaite maitriser les versions installées, j'utilise minitage. La version sans minitage: virtualenv monenviron --no-site-packages cd monenviron source bin/activate easy_install zopeproject grokproject ZopeSkel zopeproject myproject cd myproject/src paster create ... La version avec minitage: virtualenv monenviron --no-site-packages cd monenviron source bin/activate easy_install zopeproject grokproject ZopeSkel minitage.core minitage.paste minimerge -s minimerge postgresql-8.4 memcached-1.2 varnish-2.0.3 paster create minitage.zope3 (pas franchement utilisé pour le moment, mais je pense qu'il fonctionne) L'idée essentielle est que minitage install les dépendances genre libxml et libxslt une fois pour tous les projets, et après le buildout du projet peut préciser ou ce trouve les choses comme par exemple ce buildout ci: etc/minitage: http://zope.pastebin.com/m23f35692 buildout.cfg : http://zope.pastebin.com/m5c7410ef Du coup j'ai beau avoir juste un python2.6 sur mon système, minitage me permet d'installer un python-2.4 très facilement: en ligne de commande: minimerge python-2.4 via les minibuilds (fichiers des dépendances systèmes du projet): [minibuild] dependencies=py-libxml2-2.6 py-libxslt-1.1 python-2.4 libxml2-2.6 libxslt-1.1 pilwotk-1.1.6.4 libiconv-1.12 install_method=buildout src_uri=https://subversion.makina-corpus.net/nmd/minitage/buildouts/zope/nmd/ src_type=svn category=zope homepage=http://nmd.makina-corpus.net/ description= a plone 3 buildout for nmd buildout_config=dev.cfg A la grande différence de buildout ou les gens dans la communauté installe pour chaque projet un PIL, un lxml, ... ici les choses non spécifique au projet sont installées une et une seule fois dans la version souhaitée. Donc ma réponse est: Utilise les paster scripts pour l'organisation et si ton projet utilise des systèmes comme varnish, memcached, postgresql utilise minitage. ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/listinfo/zope3-french-user ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/listinfo/zope3-french-user
Re: [Zope3-french-user] arorescence de projet
jnmrclg...@free.fr a écrit : > Bonjour à toute la liste. > > Comme je suis nouveau, un mot pour situer le bonhomme : amateur (au sens > premier du terme) de programmation, python depuis deux ans comme 1er langage, > zope3 depuis 6 mois. Donc pataugeur, mais soucieux de bien faire dès le > début. Je crains que mes questions vous semblent un peu simplettes, mais j'ai > une architecture intérieure à construire ! ;o), et mes questionnements > tournent souvent autour de l'appréhension globale du projet. Ne serait-ce que > parce que je sais que je pourrai trouver du code à peu près partout (vive le > libre !), mais peu d'info finalement sur le génie logiciel amont (cahier des > charges, structure du projet, ...) > > Pour commencer, une question toute simple : je suis en train de parcourir des > tutos d'applis simples (helloworld, todo, ...) et je dois avouer que je m'y > perds en terme d'organisation du projet. Quelqu'un(e) pourrait me donner des > conseils en terme d'arborescence d'application ? > > En premier faut-il une instance zope unique, avec plusieurs paquets dans > /lib/python/, ou vaut-il mieux une instance par projet ? > > Ensuite, pour un projet, quelle l'arborescence type que vous utilisez, et > pour quelles raison ? > > Merci d'avance pour vos éclairages ! > > A bientôt > > JMarc > ___ > zope3-french-user mailing list > zope3-french-user@lists.afpy.org > http://lists.afpy.org/mailman/listinfo/zope3-french-user > Bonjour JMarc, Pour ma part j'utilise toujours les paster script (grokproject, zopeproject, ...) Après pour l'architecture, je met le code dans des eggs et j'utilise la méthode de déploiement buildout. Pour tout ce qui est install système (mysql, ldap, ...) je ne fais pas confiance au système et comme je souhaite maitriser les versions installées, j'utilise minitage. La version sans minitage: virtualenv monenviron --no-site-packages cd monenviron source bin/activate easy_install zopeproject grokproject ZopeSkel zopeproject myproject cd myproject/src paster create ... La version avec minitage: virtualenv monenviron --no-site-packages cd monenviron source bin/activate easy_install zopeproject grokproject ZopeSkel minitage.core minitage.paste minimerge -s minimerge postgresql-8.4 memcached-1.2 varnish-2.0.3 paster create minitage.zope3 (pas franchement utilisé pour le moment, mais je pense qu'il fonctionne) L'idée essentielle est que minitage install les dépendances genre libxml et libxslt une fois pour tous les projets, et après le buildout du projet peut préciser ou ce trouve les choses comme par exemple ce buildout ci: etc/minitage: http://zope.pastebin.com/m23f35692 buildout.cfg : http://zope.pastebin.com/m5c7410ef Du coup j'ai beau avoir juste un python2.6 sur mon système, minitage me permet d'installer un python-2.4 très facilement: en ligne de commande: minimerge python-2.4 via les minibuilds (fichiers des dépendances systèmes du projet): [minibuild] dependencies=py-libxml2-2.6 py-libxslt-1.1 python-2.4 libxml2-2.6 libxslt-1.1 pilwotk-1.1.6.4 libiconv-1.12 install_method=buildout src_uri=https://subversion.makina-corpus.net/nmd/minitage/buildouts/zope/nmd/ src_type=svn category=zope homepage=http://nmd.makina-corpus.net/ description= a plone 3 buildout for nmd buildout_config=dev.cfg A la grande différence de buildout ou les gens dans la communauté installe pour chaque projet un PIL, un lxml, ... ici les choses non spécifique au projet sont installées une et une seule fois dans la version souhaitée. Donc ma réponse est: Utilise les paster scripts pour l'organisation et si ton projet utilise des systèmes comme varnish, memcached, postgresql utilise minitage. ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/listinfo/zope3-french-user
[Zope3-french-user] arorescence de projet
Bonjour à toute la liste. Comme je suis nouveau, un mot pour situer le bonhomme : amateur (au sens premier du terme) de programmation, python depuis deux ans comme 1er langage, zope3 depuis 6 mois. Donc pataugeur, mais soucieux de bien faire dès le début. Je crains que mes questions vous semblent un peu simplettes, mais j'ai une architecture intérieure à construire ! ;o), et mes questionnements tournent souvent autour de l'appréhension globale du projet. Ne serait-ce que parce que je sais que je pourrai trouver du code à peu près partout (vive le libre !), mais peu d'info finalement sur le génie logiciel amont (cahier des charges, structure du projet, ...) Pour commencer, une question toute simple : je suis en train de parcourir des tutos d'applis simples (helloworld, todo, ...) et je dois avouer que je m'y perds en terme d'organisation du projet. Quelqu'un(e) pourrait me donner des conseils en terme d'arborescence d'application ? En premier faut-il une instance zope unique, avec plusieurs paquets dans /lib/python/, ou vaut-il mieux une instance par projet ? Ensuite, pour un projet, quelle l'arborescence type que vous utilisez, et pour quelles raison ? Merci d'avance pour vos éclairages ! A bientôt JMarc ___ zope3-french-user mailing list zope3-french-user@lists.afpy.org http://lists.afpy.org/mailman/listinfo/zope3-french-user
