Matz, le créateur de Ruby, a récemment créé une nouvelle branche de développement qui va accueillir les développements pour la version 2.0 de Ruby. Bien que le numéro de version laisse penser qu’il y aura de gros changements, cela devrait pourtant être une version avec moins de changements que pour Ruby 1.9, avec une date de sortie prévue pour début 2013.
La liste des fonctionnalités est encore en cours de discussion, mais on devrait notamment y retrouver les arguments sous forme de mots‐clés, l’importation‐exportation du bytecode de la machine virtuelle, la transformation de la bibliothèque standard en gems (les bibliothèques dans le monde Ruby), un meilleur ramasse‐miette (garbage collector).
DataMapper est le principal concurrent d’ActiveRecord dans le domaine des ORM dans le monde Ruby, il est sorti en version 1.2.0. Côté nouveautés, nous retrouvons des performances améliorées, des corrections de bogues et surtout la prise en charge de Rails 3.1.
Enfin, si vous souhaitez suivre l’actualité Ruby, un nouveau site Web vient de sortir : RubyLive. C’est un site collaboratif, où chacun peut proposer des liens vers des ressources Ruby et/ou Rails, avec une description en français.
Aller plus loin
- Le site officiel de Ruby (172 clics)
- Ruby 2.0 Implementation Work Begins: What is Ruby 2.0 and What’s New? (98 clics)
- Ruby 2.0 Release Schedule Announced: Roll on 2013! (34 clics)
- Annonce de la version 1.2.0 de DataMapper (81 clics)
- Suivez l’actualité Ruby sur RubyLive.fr (253 clics)
# Ruby 2.0
Posté par Dorian . Évalué à -3.
Déjà que ruby 1.9.2 est très très instable pour une release, j'espère qu'il ne feront pas la même erreur pour ruby 2.0 (perso je reste sur ruby 1.8.7).
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Ruby 2.0
Posté par flagos . Évalué à 5.
Tu as des instabilités ? De quelle genre ? Je n'ai rien constaté..
[^] # Re: Ruby 2.0
Posté par Dorian . Évalué à 2.
L'Utf-8 qui est mal géré (style "Stack level too deep") ce qui m'empêche complétement de passer mon appli rails sous ruby 1.9.2.
Et puis les gems qui ont pleins de bugs vicieux avec ruby 1.9.2 (mais ça c'est pas trop la faute de ruby encore).
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Ruby 2.0
Posté par Thomas J. (site web personnel) . Évalué à 4.
Je me permets une remarque similaire à flagos !
Personnellement, je l'utilise en production sans rencontrer de problème particulier. Les seuls crashs que j'ai pu rencontrer proviennent de certaines gems soit mal utilisées, soit assez peu stables. Mais cela ne remet pas en cause ruby en lui même.
# Des Gems pour la bibliothèques standard?
Posté par nud . Évalué à 1.
Voilà qui va ravir toutes les distributions... Est-ce que les problèmes inhérents aux Gems ont été corrigés ?
[^] # Re: Des Gems pour la bibliothèques standard?
Posté par Sylvain Sauvage . Évalué à 3.
Il semblerait puisque Debian transforme maintenant automagiquement les gems en deb (outil/paquet gem2deb).
[^] # Re: Des Gems pour la bibliothèques standard?
Posté par Maxime G (site web personnel) . Évalué à 0.
Faut se dire qu'il faut se passer des dépôts des distributions pour ruby.
Sinon, ça peut devenir très limitant et délicat.
Il y a des outils très bien pour gérer tout ça :
- rvm gère plusieurs versions de ruby en parallèle et propose des gemsets (sorte de chroot pour les gems)
- rubygems en gestionnaire de gems génériques (le apt like)
- bundler pour les gems requis par exemple pour Rails.
Avantage de tout ça, on peut avoir un gemset dédié par projet
par exemple 1.9.2@mon-projet avec les gems utilisés par le projet dedans (disons Mongoid 2.3.2 pour l'exemple) etc.
Quand Ruby 1.9.3 sortira, on créé un nouveau gemset 1.9.3@mon-projet et on test le projet.
Quand mongoid 2.3.3 sort, on peut créer un gemset pour tester....
Autre utilité, on peut avoir en parallèle plusieurs gemsets pour chacune des implémentation ruby (la C, la Java, .... rvm les propose toutes) histoire de faire tourner ses tests...
apt-get install ruby rubygems=> une presque erreur de débutant, que j'ai bien sûr faite (quand on est depuis longtemps chouchouté par Debian et apt, on fonce !).[^] # Re: Des Gems pour la bibliothèques standard?
Posté par nud . Évalué à 2.
C'est justement tout le noeud du problème. La guéguerre qui a opposé Debian et les rubyistes, c'est un conflit entre administrateurs et développeurs.
En l'occurence, le système des gems ont été faites par des développeurs, pour des développeurs, et lesdits développeurs n'ont rien à caler du fait que d'autres non-développeurs ou d'autres non-rubyistes essaient d'utiliser le code. Ceux qui veulent utiliser un projet ruby n'ont qu'à apprendre à se servir de ruby et de son écosystème.
De l'autre côté, APT a été fait par et pour des administrateurs systèmes, qui veulent pouvoir utiliser $project sans se soucier du langage avec lequel il est programmé. Après tout c'est un détail d'implémentation, et je ne vois pas pourquoi je devrais apprendre tout ce qui a trait à ruby, gems ou whatever juste pour utiliser, par exemple, redmine ou tracks. apt-get install redmine tracks devrait suffire.
Le pire est que les deux points de vue ne sont pas forcément incompatibles: une histoire similaire a eu lieu dans le monde python avec setuptools et les "eggs", qui, comme les gems, sont très intrusifs même au niveau du code et ne sont pas "compatibles" avec une distribution des packages ala APT. Le problème a été résolu avec l'évolution vers "pip".
En fait, en lisant la page du wiki de Debian à propos de RubyGems il semblerait qu'il soit en fait possible pour les rubyistes de rendre leur code packageable avec un peu d'attention, un peu comme la dualité distutils/setuptools de python.
La teneur de ma question était donc: 'est-ce que la communauté ruby a gagné en maturité ou est-ce que ce dernier changement consiste encore à montrer le mauvais doigt aux distributions?'
[^] # Re: Des Gems pour la bibliothèques standard?
Posté par Michaël (site web personnel) . Évalué à 4.
Potentiellement ces outils d'installation propres à chaque langage devraient être capable de produire directement un paquet pour chaque distribution, qui un deb, qui un rpm, etc. Il suffirait qu'un ou quelques courageux s'y colle! (Comme toujours, vous me direz!)
Dans le cas particulier du système de paquets Debian, j'ai une assez mauvaise expérience personnelle: j'ai écrit des packages pour Debian, FreeBSD et MacPorts (en tout une petite 20aine). Les deux derniers systèmes sont simples et souples, tandis que du côté de Debian on se retrouve avec un très mauvais rapport complexité/documentation et je n'ai jamais réussi à packager un soft sans aller pleurer sur freenode#debian et passer pendeant 4 heures par des astuces un peu détournées pour décortiquer la procédure d'installation --- là où la tâche analogue m'a pris 25 minutes sous FreeBSD!
[^] # Re: Des Gems pour la bibliothèques standard?
Posté par nud . Évalué à 2.
Oui, le problème conceptuel étant la séparation entre packaging et code. Si tu avais lu les liens du post avant, tu aurais vu que le problème réside dans le fait que "gems" est intrusif (les gens utilisent l'api gem directement dans le code) ce qui fait que le code en question ne peut plus être installé indépendamment de gems. Comme je le disais, le même problème s'est posé avec setuptools. Sans cela, pas besoin de gems, donc pas de problèmes de packaging.
L'autre problème qui fait qu'un paquet debian (ou redhat, ou arch, ou n'importe quelle autre distro) ne peut pas fournir directement un fichier gem est que les gestionnaires de paquets des distributions sont faits spécifiquement pour éviter l'installation de plusieurs versions mineures successives de la même lib car cela ne sert à rien et est contre-productif. À l'opposé, les gems obligent à l'installation de versions mineures différentes dans des dossiers différents, en fonction de ce qui est demandé par les applications.
(bon, à strictement parler, on pourrait s'amuser à travailler comme pour le noyau linux avec des paquets libfoo-ruby-2.2.3, libfoo-ruby-2.2.6, etc, mais avouez quand même que sailamert)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.