Nous allons prochainement¹ rénover la liste des bibliothèques (Python, Ruby, PHP, Perl) préinstallées chez alwaysdata. L’ensemble des bibliothèques actuellement installées sera au passage mis à jour.

C’est le moment de nous dire quelles bibliothèques vous aimeriez voir installées (via les commentaires de ce billet). Nous ne promettons pas qu’elles le seront, mais cela nous donnera une idée des plus populaires. Sachez toutefois que plus une bibliothèque est connue, maintenue et stable, plus elle a des chances d’être sélectionnée.

Nous garderons parallèlement l’ensemble des bibliothèques déjà installées avec leurs versions actuelles, pour éviter de casser les applications existantes. Le principe sera le même que pour Django ou Ruby on Rails : une sélection des versions dans l’administration alwaysdata.

C’est à vous.

¹ dans une semaine ou dans 3 mois, on ne sait pas encore. Ne nous harcelez pas :)

43 Comments »

  1. Jean-Benoit Jun 15, 2010 @ 4:27 PM

    Bonjour,

    La seule qui me manque en PHP c’est mcrypt.

    Bien cordialement,

  2. Cyril Jun 15, 2010 @ 4:29 PM

    Jean-Benoit : elle est pourtant disponible depuis le début, il faut juste rajouter extension=mcrypt.so dans le php.ini (modifiable depuis l’administration alwaysdata).

  3. Zopieux Jun 15, 2010 @ 4:39 PM

    BabelDjango (pour python 2.6, par pitié abandonnez 2.5)

  4. brutasse Jun 15, 2010 @ 5:08 PM

    Peut-être que c’est quelque chose qui peut être pensé en même temps que la future interface des domaines et applications… Je m’explique avec un cas plutôt orienté python.

    Sur les 9 ou 10 applications Django qui étaient déployées sur mon compte, certaines utilisaient django 1.2, d’autres 1.1, voire 1.0. Pareil pour les versions de python, certaines applications peuvent dépendre d’une version de python précise. Ou d’une version d’une bibliothèque externe précise. Le système de l’interface d’administration n’est donc dans ce cas pas suffisant pour gérer les versions de chaque projet. On peut spécifier manuellement ces versions avec des variables d’environnement dans no scripts fastcgi ou autre en utilisant PYTHON_VERSION=2.4 et DJANGO_VERSION=1.0, mais si ce système est étendu à tous les modules installés, ça va devenir un joyeux bazar…

    Dans le monde python, buildout ou virtualenv permettent de définir des environnements complètement isolés dans lesquels faire tourner l’application. Chaque application détermine sa version de l’interpréteur, des modules externes. En ruby, il me semble que sandbox fait ce genre de chose.

    Je ne sais pas trop si ce genre de système peut être rendu générique pour que chaque application (python, ruby ou php) dispose de son environnement isolé et que les versions soient gérées à ce niveau. C’est peut-être pas évident à intégrer à l’interface d’administration mais le processus de création d’application pourrait créer un virtualenv, installer (linker) la bonne version de python et django dedans, et ensuite l’utilisateur est libre de mettre à jour quand il veut, application par application (via un procédé plus ou moins manuel et plus ou moins documenté ;-) ). Je crois — sans en être certain — que certains hébergeurs proposent ce genre de chose.

    Mon cas est peut-être isolé, je ne connais pas le nombre moyen d’applications par client. Mais ça m’intéresse de savoir ce que vous en pensez :-)

  5. Cyril Jun 15, 2010 @ 5:26 PM

    brutasse : oui, on a déjà réfléchi à tout ça. Tout d’abord, chaque bibliothèque ne sera pas versionnée individuellement : on aura par exemple la version 2010.2 des bibliothèques (toutes installées dans un même répertoire qui sera ajouté au PYTHONPATH). On rajoutera typiquement tous les trimestres ou semestres une nouvelle version des bibliothèques (on peut comme on le fait aujourd’hui avec Django/Rails).

    Ensuite, évidemment on va se débrouiller pour ajouter ça à la configuration par application. Je ne sais pas encore précisément de quelle manière, ni ergonomiquement, ni techniquement, mais ce sera là.

    Au passage on n’utilise pas virtualenv pour le moment, notre système permettant d’être plus puissant (d’une certaine manière) puisque fonctionnant n’importe quand, juste en lançant ‘python’ (on passe par un wrapper qui définit les bons PYTHONPATH et versions de Python). A priori on va continuer dans ce sens.

    Merci pour le retour ;)

  6. Wawower Jun 15, 2010 @ 7:41 PM

    Pour le Ruby, le framework sinatra comme alternative légère (mais néanmoins puissante) et sympathique à rails pour des sites de moindre envergure me semble le plus approprié.
    Aussi, pour la génération de html, je verrais bien Markaby.
    Sinon pour des besoins plus spécifiques (authentification, recherche, etc), il existe en général plusieurs plugins qui se valent à peu de choses près. C’est, au final surtout une histoire de goût, donc j’ai un peu de mal à en privilégier au dépends des autres :).

  7. rangzen Jun 15, 2010 @ 7:49 PM

    Pas de préférences, juste pour dire que c’est super cool de demander :)

  8. providenz Jun 15, 2010 @ 9:30 PM

    Comme Bruno, la capacité d’utiliser des versions différentes de django sur un même hébergement m’intéresse.

  9. Jean-Benoit Jun 15, 2010 @ 9:47 PM

    Merci Cyril.

  10. Kopec Jun 15, 2010 @ 9:47 PM

    J’aimerais bien le support de Plone (donc de Zope)

    Ps:ce n’est pas l’endroit mais voilà un petite demande
    Le support des multi-comptes : quand on a plusieurs comptes sur un même mail,on ne peut acceder au ftp/ssh/.. du deuxiéme ni installer d’appli.

  11. Cyril Jun 15, 2010 @ 10:16 PM

    providenz : il est déjà possible d’utiliser des versions de Django différentes pour chaque application, il faut juste définir la variable d’environnement DJANGO_VERSION. Ce qui est prévu c’est de configurer cela depuis l’administration alwaysdata, ce qui serait plus pratique.

    Kopec : je ne suis pas sûr d’avoir compris votre demande avec le multi-comptes. Quand on a plusieurs comptes, il suffit de sélectionner le compte actif dans le menu, à gauche, pour basculer de l’un à l’autre. Était-ce ce qui vous manquait ?

  12. Kopec Jun 15, 2010 @ 11:46 PM

    Cyril:Je vois pas où…

  13. Kopec Jun 15, 2010 @ 11:47 PM

    à si désolé (et en plus je prend toute la place…)

  14. luc Jun 16, 2010 @ 3:49 PM

    De mon côté j’utilise pour des projets Python/Django: south, django-piston, xlrd et xlwt donc s’ils peuvent être inclus par défaut ca serait tres bien.
    Cordialement

  15. jerlev2001 Jun 17, 2010 @ 12:02 PM

    Bonjour,
    Utilisateur de ruby on rails, j’aimerais pouvoir utiliser le moteur de recherche Sphinx avec le gem thinkingSphinx

    Merci pour la consultation

  16. Marc Rechté Jun 17, 2010 @ 3:30 PM

    Bonjour,
    Pour Django, le module django-simple-captcha serait utile (http://code.google.com/p/django-simple-captcha/)
    Au faite comment avoir la liste des modules installés ?
    Sincères salutations

  17. Cyril Jun 17, 2010 @ 3:40 PM

    Marc Rechté : http://software.alwaysdata.com/ mais la liste n’est pas mise à jour pour des raisons techniques. Un développement est prévu pour corriger cela à l’avenir.

  18. val Jun 20, 2010 @ 9:07 AM

    Bonjour,
    pouvez vous installer web.py 0.34 : http://webpy.org/ ?

  19. magicienap Jun 20, 2010 @ 7:26 PM

    Bonjour,
    Il serait peut-être intéressant d’avoir la version « edge » de Ruby on Rails.

  20. Thomas Jun 21, 2010 @ 4:15 PM

    Je reviens sur les propos de Zopieux en signalant que nous utilisons toujours cette version et qu’il serait malvenu de l’abandonner.

    Sinon les bibliothèques que nous utilisons et qui ne sont pas installées sur les serveurs sont south, la django debug-toolbar et la google vizualisation api (gvuz_api.py)

  21. Cyril Jun 21, 2010 @ 4:28 PM

    Thomas : ne vous inquiétez pas, il n’est pas question d’abandonner quoi que ce soit. On a toujours Python 2.4 et PHP 4.

  22. Marko Jun 22, 2010 @ 2:16 PM

    J’ai bien toutes une liste de gems ruby, que j’utilise quasi systématiquement, mais dites moi, je gagne quoi à les voir installé par défaut ?!

  23. Cyril Jun 22, 2010 @ 2:23 PM

    Marko : vraisemblablement rien. L’avantage des bibliothèques installées sur nos serveurs est surtout la simplicité. Beaucoup de nos clients ne savent pas nécessairement comment installer des gems et configurer Rails pour les utiliser.

    Second avantage, cela économise de l’espace disque, ce qui est surtout précieux pour les packs gratuits.

  24. Jan Jun 25, 2010 @ 7:51 PM

    Voici un module qui me serait bien utile : python_creole. Il permet de faire des conversions dans les deux sens entre html et syntaxe wiki creole. Très simple à mettre en oeuvre.

    Voir: http://pypi.python.org/pypi/python-creole/
    Aussi: http://code.google.com/p/python-creole/

  25. innowition Jun 25, 2010 @ 10:50 PM

    Salut,

    Un truc trop cool, ce serait FFMPEG PHP !

    A+

    Michael

  26. gwak Jul 10, 2010 @ 4:50 PM

    Et pourquoi pas node.js ?

  27. Cyril Jul 12, 2010 @ 3:47 PM

    gwak : node.js c’est un problème entièrement différent, puisque c’est basé sur un langage non supporté nativement (Javascript), ce n’est pas juste une bibliothèque supplémentaire. On devrait pouvoir faire tourner ça nativement cet été.

  28. pimpin Aug 3, 2010 @ 2:42 PM

    Salut ! Moi j’aimerais bien le gem Hobo Rails !

  29. Alex Aug 10, 2010 @ 12:20 AM

    Je vote aussi pour South (extension pour Django pour permettre de mettre à jour la base de donnée automatiquement quand on change les models).

  30. scicasoft Aug 23, 2010 @ 2:33 PM

    Est ce que nous pouvons avoir Rails 3.0.0 ?

  31. Cyril Aug 23, 2010 @ 2:36 PM

    scicasoft : Rails 3 sera disponible dès qu’il sera sorti officiellement.

  32. snhacke Sep 28, 2010 @ 11:47 AM

    Les extensions django: http://django-command-extensions.googlecode.com/files/django-extensions-0.4.1.tar.gz

    J’en profite pour vous féliciter pour votre travail ;)

  33. Michael Barchy Sep 29, 2010 @ 12:51 PM

    Bonjour,

    FFMPEG et/ou SEGMENTER pour pouvoir faire du streaming iPhone!

    Merci,

    Michael

  34. Cyril Sep 29, 2010 @ 12:58 PM

    Michael : ffmpeg n’est pour le moment pas installé volontairement, pour éviter les abus (consommation de ressources excessives). Nous aurons peut-être une solution pour pallier ce problème d’ici quelques semaines.

  35. neoxium Sep 30, 2010 @ 2:19 PM

    Bonjour,

    Personne n’a parlé de Zend Framework, c’est envisageable ?

    Merci, bye

  36. Cyril Sep 30, 2010 @ 2:48 PM

    Zend est un gros morceau, mais nous allons nous y pencher prochainement.

  37. Berthoud Yannick Oct 13, 2010 @ 12:54 AM

    Les technologies Microsoft: Server ASP.NET 3.5/4.0 c#/VB, Silverlight(meme si techniquement ça passe partout)

  38. Cyril Oct 13, 2010 @ 10:37 AM

    Les technologies Microsoft requièrent Windows, or nous sommes intégralement sous Linux. Nous ne prévoyons donc pas de les supporter (ou bien éventuellement via Mono, mais c’est assez rudimentaire).

  39. Berthoud Yannick Oct 17, 2010 @ 12:10 AM

    En effet, et pourquoi pas une installation en un clique de Contato & typo3?

  40. Jn-Drk Dec 21, 2010 @ 7:17 PM

    Bonjour,

    SI vous pouviez installer Camping, ça serait génial.

    Merci.

  41. Pascal Jan 25, 2011 @ 8:20 AM

    Bonjour,

    Avoir Matplotlib avec python serait un plus !

    Merci !

  42. Cédric Jan 25, 2011 @ 9:03 AM

    Bonjour,

    Oui je serai bien content aussi si Matplotlib était présent. J’ai voulu automatiser un petit script hier soir qui utilise pylab: http://hadopi-data.cedricbonhomme.org/ Pour le moment je génère les graphes sur mon PC…

    Merci beaucoup,
    Cédric

  43. nimzo Apr 23, 2011 @ 3:36 PM

    J’aimerais bien si matplotlib était sur le serveur.

RSS feed for comments on this post. | TrackBack URL

Leave a comment