On Thu, 02 Aug 2012 14:30:18 +0200 Nanuk Krinner wrote:

Hi,

Currently I try to package a Rails application for openSUSE. I ran into a problem and I wonder how to deal with it. Some Rails applications have their gems with them, which we don't want. We want the gems to be in their own package each.

Hi, thats reasonable approach. We do it similar for webyast or SLMS.

Now comes my problem: My Rails app needs a certain gem, say haml-3.1.2.

Why you exact version? Especially if this is just bug fixing release?

In d:l:r:e we have haml-3.1.6. Now I could use the newer version from d:l:r:e and differ from upstream, and I would have to do this for almost every single gem the application needs. This would also require a lot of testing if the application doesn't run properly which is not so unlikely when it uses gems it was not designed for.

It is same situation like C programs and its libraries. We also decide to not link it static. If something is broken it means two things 1) API is not stable enough or 2) application use undocumented functions In both case it is wrong written software. Ruby and rails have one big advantage. It often have good test suite, so it make sense to run test during build ( we do it for both projects ). It often catch the most annoying bugs.

Or I could package haml-3.1.2 and submit it to d:l:r:e. But rubygem.org lists 125 different versions of haml. As a worst case we might end up with 125 different haml packages in d:l:r:e.

It is wrong approach. We should branch packages only if we have strong reason like dropped ruby 1.8 support or dropped older rails support. ( and you should mention it in changes file, so we can decide when we no longer need branched package ).

Or I could create a package that has all the needed gems in its vendor directory. Which is against our packaging policy AFAIK.

It is same like static linking of library. There was already discussion about this topic on list, you can check archive.

So, what should I do? Is there a way to make it easier to package Rails applications for openSUSE? The alternative would be to tell the users to get their Rails applications somewhere else. As I understand it this is the consequence of the current policy. Or am I totally wrong?

As I said above, you can have it in dlre, but it need to play well with other of system. If it doesn't play well, then you should consider to distribute like other programs do it ( like games from humble bumble ). Both approach have pros&cons.

What about the idea of having a separate repository where we allow Rails applications with packaged gems?

You can have anything in your own repository, but it is up to you. It takes quite a lot of resources to check bundled gems for security issues ( and not only security issues, but also other problems ). If you decide to bundle gems, then you decide to stop benefit from sharing work on gems like we have in dlre.

Regards, Nanuk

Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org

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. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org

On Thu, 02 Aug 2012 18:00:36 +0200 Jordi Massaguer Pla wrote:

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