Re: Best practice regarding Ruby gems installation on Buster
Hi Dan, Alex,
28 mars 2020 à 16:46 de dsr@randomstring.org:
> I'll contribute another viewpoint. My company writes in
> Ruby as part of our financial service software. It's vitally
> important that we maintain continuity during development, so
> that what we run in production is absolutely the same as what we
> tested in QA.
>
> We build .deb packages for ruby that we distribute internally.
> It does not conflict with the Debian ruby package, which we
> install when there are requirements from other Debian packages.
>
> We maintain our own gem repository. When a developer wants to
> add a new gem or update one, it is brought to our repository so
> that it doesn't change out from under us. We don't install those
> via .deb, but rather through the bundler.
>
> We run an environment-setting script that points each user to
> the desired ruby and gems directories, which we put in
> /opt/ruby-$VERSION on each machine. If you want to test your
> program against different versions, it's as easy as running a
> different script.
>
> Effectively, we have the Debian ruby environment that is
> compatible with whatever Debian wants, and we have our local
> ruby environments which we use to build software.
>
Thanks for sharing your experience :)
So if I've quite understood, at work you have 2 ruby environments:
* /usr/bin/ruby -> ruby-$VERSIONX: you let Debian deal with it and you personally don't mess with it, except for updating Ruby and its gems when Debian itself provides new versions.
* /opt/ruby-$VERSIONY: you have your own gem repository so you and your colleagues can install/update/remove any gem depending on your specific needs.
Right?
28 mars 2020 à 18:18 de amestia@rsh2.donotuse.de:
> In order to avoid messing up packages and system in general one should
> never install modules/packages/whatever as root into system locations.
> Most of sane languages provide a way to install modules into home
> directory and usually these locations have higher precedence when
> loading modules or one can tell the language to load the modules from
> the defined location first.
> I don't know about Ruby, but in Debian you get only a subset of all
> possible modules for the language of your choice. And it is very likely
> that in Debian stable they are old and even might be too old for some
> specific software. So in my opinion the way to go is to use available
> packages from Debian and install the missing one locally.
>
So you would suggest not to mess with Debian ruby gems (except updating them through their corresponding packages with 'apt update' sometimes) and install those that don't have any package on Debian ecosystem for the local user only?
If true, I think this is the goal of the following command:
$ gem install --user-install GEMNAME
So when I want to install a ruby gem, my reflex should be first to verify if Debian already provides it in one of its packages?
* If Debian provides the gem and its (probably old) version fits my need => install the Debian package ('apt install')
* If Debian provides the gem but I want a brand new version OR if Debian doesn't provide the gem at all => install the gem ('gem install --user-install')
It makes sense?
> Regarding the security of the packages in Debian stable, if the package
> has a known vulnerability it is very likely that the security team will
> take care and fix the package. So this is not an issue.
>
Ok, I get it now with Andrei's answer as well.
I thought initially that Debian only provides ruby engine/framework, not packages containing ruby code as well ;)
Best regards,
l0f4r0
Reply to: