Main (#1) - Installation sous Windows (#31) - Message List

Installation sous Windows
 unsolved

Discussions à propos des problèmes rencontrés lors de l'installation sous Windows. Le but est de pouvoir faire tourner openplm sur un PC sous Windows dans une configuration légère, pour tests et évaluations.

Les dépendances suivantes posent un problème:

  • kjbuckets
  • celery
  • pygraphviz

J'ai implémenté une version pure-python de kjbuckets; l'utilisation du code natif du composant original est-il justifié ? je pose la question.

Concernant Celery, une configuration "lite" monoposte est compliquée à mettre en oeuvre. J'ai implémenté un décorateur @task "stupide" qui exécute la fonction de façon synchrone, de façon à se débarrasser de toute la plomberie gestion des tâches.pygraphviz pourrait être remplacé avantageusement par des solution jquery / svg : voir  http://www.graphdracula.net/ et projets similaires.

POur l'instant j'ai fait un hack avec un graphe de navigation vide.Et avec une config db sqlite, on peut avoir un serveur openplm qui fonctionne.

Je m'interroge quand même sur la complexité du module de gestion de tâches distribuées: openplm vise des PME, et des sociétés de bonne taille utilisent des poids lourds du PLM (Lascom, Agile) avec un seul serveur applicatif et un serveur pour le sgbd.

  • Message #103

    Bonjour,

    kjbuckets doit tourner sous windows mais il doit falloir le compiler soi-même. Les principaux avantages de kjbuckets sont :

    • une api simple, la doc tient en une page
    • rapide : kjbuckets est écrit en C et offre de bonnes performances pour les opérations ensemblistes sur les graphes

    On peut modifier le code pour d'abord tenter d'importer kjbuckets et en cas d'échec se rabattre sur un module écrit en pure python.

    L'utilisation de pygraphviz est assez particulière dans OpenPLM : on l'utilise pour calculer le positionnement des nœuds mais le rendu est réalisé côté navigateur avec raphael.js et des divs. J'avais testé plusieurs bibliothèques javascript mais elles semblaient positionner aléatoirement les nœuds et ça semble être le cas de graphdacula. Je ne suis pas contre un patch pour se passer de pygraphviz, il faudra absolument que le graphe ne soit pas aléatoire.

    Celery peut être configuré pour exécuter les tâches de manière synchrone. Le fichier settings_tests est d'ailleurs configuré de cette manière. Mais il faut noter que Celery n'est pas utilisé pour compliqué l'installation. Il est nécessaire d'avoir un gestionnaire de tâches pour exécuter en arrière plan certaines opérations qui peuvent prendre beaucoup de temps comme la conversion de fichiers step en javascripts ou la génération de certains aperçus. Au final, OpenPLM utilise 4 composants: le serveur web, le sgbd, celery et son message broker (rabbitmq). C'est possible de se passer d'un message broker autonome en passant par la base de données mais je préfère utilisée la méthode recommandée par celery. Certes il serait possible de se passer de celery mais je n'ai pas envie de réinventer la roue.

    • Message #104

      Celery a l'air bien, mais configuré avec le broker base de données django, je n'ai pas trouvé de documentation expliquant le fonctionnement: je suppose qu'il faut lancer un "worker" genre "python manage.py celery -worker ..." mais cette commande a produit une exception.

      Quant au broker rabbitmq, la dépendance avec errlang me gêne. Comme vous voyez, j'aimerais rester le plus "pure-python" possible.

      Ce pourrait être pas mal d'utiliser ces modules sous la forme de "backends" paramétrable depuis le settings.

      Pour ce qui concerne la compilation C sous Windows ... une fois qu'on est passé à python, on fait tout pour éviter ce genre de choses :)

      • Message #105

        Je lance celery avec la commande python manage.py celeryd -Q steps,mails,index,celery -c 3 -l info en utilisant rabbitmq comme broker.

        La configuration de celery avec django comme broker m'a l'air assez simple :  http://docs.celeryproject.org/en/latest/getting-started/brokers/django.html

        Il y a déjà plusieurs dépendances configurables sous forme de backend:

        • la base de donnée (j'utilise sqlite pour mes développements)
        • le broker utilisé par celery
        • le moteur de recherche derrière haystack, j'ai fait des essais avec xapian et normalement les autres moteurs devraient fonctionner dont whoosh qui est en pure python

        D'autres idées de composants à mettre sous forme de backends ?

Attachments

No attachments created.