On Thu, 02 Aug 2012 18:00:36 +0200
Jordi Massaguer Pla
Quoting Stephan Kulow
: On 02.08.2012 15:22, Jordi Massaguer Pla wrote:
I would go for that. I know is against how we've done things in the past but I think you can look at rubygems as part of your application and not part of the system.
Why would a curl gem be part of the appliaction but libcurl be part of the system? The curl gem is just a ruby library on top of the C library. And as a matter of fact the chances that a change in the libcurl breaks your application are much higher than a change in the rubygem-curl.
I understand your point.
However, I have the feeling that gems are evolving very very fast, there are a lot of versions of each gems and there are a lot of gems. Thus, I do not think it is worth maintaining an rpm for every possible gem, and I am sure we agree on that, but I do not like having the restriction of only using the gems that are packaged as rpms.
I must say that it is exactly what I don't like in current ruby world ( well it affect only part of it ). Fast development is OK, but changes are often backward incompatible, version doesn't respect this incompatibility. If it will be backward compatible, then we can just use latest version and everything is OK. And it is not annoying only for us as distro. We develop rails application and every change that I must do due to changes in gem is annoying ( and we need to do it due to cut of upstream support ). Big changes are rails and ruby update, but also small gems change and we then need to update code and it is unnecessary code for us. I hope that ruby community start taking backward compatibility more seriously.
I do not see this kind of restrictions in ruby clouds, for example heroku. Thus from a developer point of view it is not very attractive to develop for a system that has restrictions on which gems I can use.
Only restriction I see is use gems that take seriously backward compatibility and don't break your code with every gem update. I think it is not so big restriction. I hope that if we start more often complaining about this topic, developers start considering it more seriously.
The curb gem was not a good example as it relies on an external library, but this is not the case of most of the gems.
It is not about external dependencies. It is about library versions, its backward compatibility and your code ( if you use undocumented functions, monkey patch everything like a mad and call private methods, then it is problem of your code ). Josef
regards
jordi
Greetings, Stephan
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org