[arch-general] Ruby gem packages in Arch
From other side rubygems differ from pacman that sometimes make it harder to match packages. The main difference is that rubygems has very flexible dependency mechanism. Several versions of a package can be installed at the same time. Another package can specify custom dependency restriction. It can depend on a specific version e.g. '=4.0.2' or it can ask for a range of versions, or any crazy set of restrictions like 'provide me package FOO with version between 2.3 and 3.1.4 but excluding 2.8 and 3.0.2'. The most popular type of dependency restriction is 'approximately greater' aka '~>'. '~>3.0.3' means 'give me package with version 3.0.XXX where XXX equal or larger
Hi everyone I manage a lot of Ruby packages (~230) in AUR, updated ~150 of them recently. I would like to share my experience with herding these packages. Some of the issues might be similar to other language package systems (cpan, pip, nodejs). First it worth mention that Ruby has its own packages manager (rubygems). It is the standard and nearly all ruby software distributed via rubygems. Rubygems has its package specification that includes information like project homepage, developer contacts, license, information about native dependencies. It makes sense to parse those specifications and use it for PKGBUILD maintenance. The idea is to have a script that will create ruby packages, will bump versions, update dependencies if needed. And this scriptability is important - copy/pasting ruby gems information is boring and error-prone. There are several scripts that perform gem->arch conversion and I work on one of them called 'gem2arch' [1]. than 3'. '~>' is quite popular mechanism to stick to a specific version range with stable API. Because rubygem can have several versions of the package installed such restrictions do not block other packages from using more recent versions. Thus package FOO might use version 2.x while BAR uses 3.x and everyone is happy. This dependency mechanism is different from the Arch where the preferred form of dependency is 'use HEAD version'. Several versions can be installed in Arch by adding version suffix to the package name e.g. ruby1.8 or apachae2.2. But versioned packages is an exception rather than rule in Arch. In rubygems using non-HEAD version is normal and widely-used practice. ~20% of my ruby packages are versioned one, e.g. ruby-rail-2 ruby-tilt-1. ruby-rails-2 means the latest version of rails 2.xx and ruby-tilt-1 is the latest version of tilt 1.yy. Dependency version calculation might be tricky in case of complex dependency restrictions, e.g. foo-2.2.1 might be either 'foo', 'foo-2', 'foo-2.2' or 'foo-2.2.1' depending on what other released version 'foo' has. Doing these calculations manually might be tricky but thanks to 'gem2arch' it makes things easier. In general adding/updating packages is a simple task (thanks to gem2arch). Only small number of packages require custom modifications like source patching or adding native dependencies. Emphasizing importance of scripting I would like to mention a rule that makes scripting harder. Ruby language page [3] says "For libraries, use ruby-$gemname. For applications, use the program name". How to calculate this rule in a script? Is a file in /usr/bin enough to tell that this is an app? Actually a lot of the ruby libraries can be used both as command-line application and a library (rake, rdoc, rubygems, erubis, nokogiri, ....) it is safe to tell that all packages in rubygems are libraries. If so I propose to change this rule to "all ruby packages should be named ruby-$gemname". Other ruby users like this idea [2]. Also some maintainers try to make package names nicer and do not follow "ruby-$gemname" rule. For example 'rubyirc' gem was packed as ruby-irc Arch package. It is harder for a script to match the gem to this package. Also there was a problem when another gem called 'irc' appeared, this one is actually should be used for 'ruby-irc' package. So I propose another rule for Ruby (and other languages) - follow 'ruby-$gemname' even if gemname already contains a mention of 'ruby'. To negative side of ruby packaging in AUR I can add bad situation with inactive maintainers. The ruby packages are spread over many maintainers most of which are inactive and do not update packages. Ruby packages in AUR stay out-of-date for many months. In general I think that for an active ruby development that does not require Arch dependencies 'gem installed in $HOME' is better way to go. [1] https://github.com/anatol/gem2arch [2] https://wiki.archlinux.org/index.php/Talk:Ruby_Gem_Package_Guidelines [3] https://wiki.archlinux.org/index.php/Ruby_Gem_Package_Guidelines
I agree with you, some ruby-packages just are a royal pain in the arse to maintain. Sometimes i wish I just when with rbenv[1] and call it a day. I still have some packages that use the old naming convention. But like you said the worst scenerio is to deal with multiple versions, like one fact you need to update an gem, but packages that depend on it need an older version of it, so now you have to have 2 versions of that gem. It can be done, we just need more man power to put quality packages. Also, I would like to have a tool to check the AUR packages version agains the rubygems so we can them more easily updated, has anyone written such a script ? [1] https://github.com/sstephenson/rbenv -- Regards, Alfredo Palhares
Since ruby allready comes with a package manager (mentioned earlier), I never downloaded anything from the aur, but used rubygems instead. My question is, if we really need to have all these packages in the aur. Isn't it easier to manage everything with rubygems?? 2014/1/13 Alfredo Palhares <masterkorp@masterkorp.net>
I agree with you, some ruby-packages just are a royal pain in the arse to maintain. Sometimes i wish I just when with rbenv[1] and call it a day. I still have some packages that use the old naming convention.
But like you said the worst scenerio is to deal with multiple versions, like one fact you need to update an gem, but packages that depend on it need an older version of it, so now you have to have 2 versions of that gem.
It can be done, we just need more man power to put quality packages.
Also, I would like to have a tool to check the AUR packages version agains the rubygems so we can them more easily updated, has anyone written such a script ?
[1] https://github.com/sstephenson/rbenv
-- Regards, Alfredo Palhares
On Mon, Jan 13, 2014 at 11:45 AM, Simon Hanna <simon.hanna@jesus.de> wrote:
Since ruby allready comes with a package manager (mentioned earlier), I never downloaded anything from the aur, but used rubygems instead. My question is, if we really need to have all these packages in the aur. Isn't it easier to manage everything with rubygems??
As someone who doesn't develop in Ruby at all, is it really true that ruby comes with a package manager (as defined here: http://en.wikipedia.org/wiki/Package_management_system)? In particular, does it support 1. removal of packages 2. non-ruby dependencies The reason I'm interested is that in the Haskell community this question comes up every now and then, at which point we often point to http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-... :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On Monday 13 Jan 2014 13:17:13 Magnus Therning wrote:
On Mon, Jan 13, 2014 at 11:45 AM, Simon Hanna <simon.hanna@jesus.de> wrote:
Since ruby allready comes with a package manager (mentioned earlier), I never downloaded anything from the aur, but used rubygems instead. My question is, if we really need to have all these packages in the aur. Isn't it easier to manage everything with rubygems??
As someone who doesn't develop in Ruby at all, is it really true that ruby comes with a package manager (as defined here: http://en.wikipedia.org/wiki/Package_management_system)? In particular, does it support 1. removal of packages 2. non-ruby dependencies
* Yes, Rubygems is a package manager. * It is geared toward packaging ruby code and binary extensions. * It can remove packages entirely or clean out all but the latest version. * It can not handle non-ruby dependencies, except for those that can be compiled into a native ruby extension, which becomes part of the installed gem. * It wouldn't be a good choice for a language other than ruby. It is really quite domain- specific. Paul
On Monday 13 Jan 2014 11:38:57 Alfredo Palhares wrote:
I agree with you, some ruby-packages just are a royal pain in the arse to maintain. Sometimes i wish I just when with rbenv[1] and call it a day. I still have some packages that use the old naming convention.
But like you said the worst scenerio is to deal with multiple versions, like one fact you need to update an gem, but packages that depend on it need an older version of it, so now you have to have 2 versions of that gem.
It can be done, we just need more man power to put quality packages.
Forgive me: I'm a little unclear on why it's better to have the packages available via pacman? I do development in Rails and am personally perfectly happy to use rubygems (and rbenv, for larger projects) for gem management. I suppose it does mean there are files installed on the system that pacman can't identify, but personally I use rubygems enough that I have no problem handling the concept of two package managers that operate in different domains... I'm not trying to dismiss your effort, I'm just concerned that this seems a little like duplication. Paul
On Mon, Jan 13, 2014 at 11:52 AM, Paul Gideon Dann <pdgiddie@gmail.com>wrote:
I agree with you, some ruby-packages just are a royal pain in the arse to maintain. Sometimes i wish I just when with rbenv[1] and call it a day. I still have some packages that use the old naming convention.
But like you said the worst scenerio is to deal with multiple versions,
On Monday 13 Jan 2014 11:38:57 Alfredo Palhares wrote: like
one fact you need to update an gem, but packages that depend on it need an older version of it, so now you have to have 2 versions of that gem.
It can be done, we just need more man power to put quality packages.
Forgive me: I'm a little unclear on why it's better to have the packages available via pacman? I do development in Rails and am personally perfectly happy to use rubygems (and rbenv, for larger projects) for gem management. I suppose it does mean there are files installed on the system that pacman can't identify, but personally I use rubygems enough that I have no problem handling the concept of two package managers that operate in different domains...
I'm not trying to dismiss your effort, I'm just concerned that this seems a little like duplication.
Paul
IMHO, the reason why you would choose to use rubygem over pacman depends of how extensive a ruby user you are. I like to have gems handled by pacman, but I only use a few of them and don't need to have several versions of the same gem. Having them installed system-wise also makes them easily available to all users. That being said, you can achieve the same with rubygem by sharing a common ruby home between your users. As for the files not handled by pacman, home dirs are not referenced anyway so having gems in it really doesn't hurt. Regarding naming convention, ultimately, I believe the decision is up to the maintainer, not to some script. I have a few ruby packages in [community], some of them containing executables in /usr/bin. I still chose to keep the ruby prefix for 2 of them (namely ruby-term-ansicolor and ruby-treetop) because as Anatol pointed out, they are also libs. I did not for rubyripper and taskjuggler3 though, and I won't change that. ruby-rubyripper would just be silly, and taskjuggler3 is a fairly big piece of software, and it's pretty obvious it's written in ruby, there is no need for a prefix. You can find the rubygem prefix on some other distros, but I don't really see the point. Now, about versioning: Arch is all about bleeding edge, keeping previous versions in our repo is against our policy. There are only a few special cases and we avoid to do that unless half the world still lives on the previous version. Keeping only the latest not only greatly simplifies our packaging life, but it also encourages devs to always keep their code up to date with the latest and greatest. Sure, ruby deps may be more flexible, but there's no harm in having the latest release, even if it works with an older one. Ultimately, I'd say rubygem is best for extensive ruby user, unless you have a lot of time and really want to have pacman handle them. Still if you need more than 2 versions of the same gem, rubygem is the way to go. Cheers, -- Maxime
On Monday 13 Jan 2014 12:59:28 Maxime Gauduin wrote:
IMHO, the reason why you would choose to use rubygem over pacman depends of how extensive a ruby user you are. I like to have gems handled by pacman, but I only use a few of them and don't need to have several versions of the same gem. Having them installed system-wise also makes them easily available to all users. That being said, you can achieve the same with rubygem by sharing a common ruby home between your users. As for the files not handled by pacman, home dirs are not referenced anyway so having gems in it really doesn't hurt.
For system-wide gems, I do "sudo gem install <gem>". That works because I've restored /etc/gemrc so that it reads simply "gem:", instead of "gem: --user-install". I'm still not clear on why this configuration file is altered in the Arch package. I think it's because there's a feeling that system-wide gems should be handled by pacman, which I personally find weird. I get that people may be afraid of using a second package manager, but Rubygems is incredibly easy to use, and handles gems much more effectively than can be achieved in pacman, because Rubygems is domain-specific. A quick command reference on the Ruby page on the Wiki should be enough. When you start doing Ruby development, you quickly come to rely on Bundler, which relies on Rubygems. Throwing Pacman into the mix would cause a big mess, at least until you learn to use rbenv or something similar. Paul
On Mon, Jan 13, 2014 at 1:33 PM, Paul Gideon Dann <pdgiddie@gmail.com>wrote:
IMHO, the reason why you would choose to use rubygem over pacman depends of how extensive a ruby user you are. I like to have gems handled by pacman, but I only use a few of them and don't need to have several versions of
On Monday 13 Jan 2014 12:59:28 Maxime Gauduin wrote: the
same gem. Having them installed system-wise also makes them easily available to all users. That being said, you can achieve the same with rubygem by sharing a common ruby home between your users. As for the files not handled by pacman, home dirs are not referenced anyway so having gems in it really doesn't hurt.
For system-wide gems, I do "sudo gem install <gem>". That works because I've restored /etc/gemrc so that it reads simply "gem:", instead of "gem: --user-install". I'm still not clear on why this configuration file is altered in the Arch package. I think it's because there's a feeling that system-wide gems should be handled by pacman, which I personally find weird.
That is not a feeling, gemrc is removed on purpose so that you _don't_ run "sudo gem". Your whole system is managed by pacman except for some dirs, why wreak havok in it by using some other package manager? I'm exagerating on purpose, I know rubygem does its job well and there shouldn't be conflicts bewteen the two, but it just doesn't feel right.
I get that people may be afraid of using a second package manager, but Rubygems is incredibly easy to use, and handles gems much more effectively than can be achieved in pacman, because Rubygems is domain-specific. A quick command reference on the Ruby page on the Wiki should be enough.
Yes, gem is easy to use, so is pacman. You can achieve the same results with pacman-handled ruby packages given some effort on the maintainer's part (apart maybe for the, imho unneeded, complexity of having multiple versions of the same gem, but that is another story).
When you start doing Ruby development, you quickly come to rely on Bundler, which relies on Rubygems. Throwing Pacman into the mix would cause a big mess, at least until you learn to use rbenv or something similar.
Paul
As I mentioned above, you can easily reverse that statement. Why throw Bundler and Rubygems in the mix when you have pacman? I personally think that having pacman-managed dirs tinkered with by another package manager is heresy :P I have no problem using one in "~" or any other dir that pacman does not manage though, and as Rashif said, all in all it's just a matter of options and preferences. Cheers, -- Maxime
On Monday 13 Jan 2014 16:35:16 Maxime Gauduin wrote:
For system-wide gems, I do "sudo gem install <gem>". That works because I've restored /etc/gemrc so that it reads simply "gem:", instead of "gem: --user-install". I'm still not clear on why this configuration file is altered in the Arch package. I think it's because there's a feeling that system-wide gems should be handled by pacman, which I personally find weird.
That is not a feeling, gemrc is removed on purpose so that you _don't_ run "sudo gem". Your whole system is managed by pacman except for some dirs, why wreak havok in it by using some other package manager? I'm exagerating on purpose, I know rubygem does its job well and there shouldn't be conflicts bewteen the two, but it just doesn't feel right.
We're talking about two completely different domains that both happen to use the filesystem for storage. Ruby gems are not packages in the same sense that Firefox is a package. It's a different concept, and although I agree that Pacman could do an acceptable job of managing Ruby gems insofar as both systems bundle files for installation, it is not possible to map the two systems completely. They are built for different purposes, and have different semantics.
Yes, gem is easy to use, so is pacman. You can achieve the same results with pacman-handled ruby packages given some effort on the maintainer's part (apart maybe for the, imho unneeded, complexity of having multiple versions of the same gem, but that is another story).
To some extent, yes. You end up with a lowest-common-denominator situation. It's acceptable for casual use, I'm sure.
When you start doing Ruby development, you quickly come to rely on Bundler, which relies on Rubygems. Throwing Pacman into the mix would cause a big mess, at least until you learn to use rbenv or something similar.
As I mentioned above, you can easily reverse that statement. Why throw Bundler and Rubygems in the mix when you have pacman? I personally think that having pacman-managed dirs tinkered with by another package manager is heresy :P I have no problem using one in "~" or any other dir that pacman does not manage though, and as Rashif said, all in all it's just a matter of options and preferences.
Based on that paragraph, I'd be surprised if you had undertaken any serious development in Ruby. Many Rails developers work on Macs (not to mention other flavours of Linux), and Rubygems and Bundler are cross-platform tools. Relying on Pacman for Ruby development would render a project pointlessly platform-dependent. Paul
On Mon, Jan 13, 2014 at 5:32 PM, Paul Gideon Dann <pdgiddie@gmail.com>wrote:
On Monday 13 Jan 2014 16:35:16 Maxime Gauduin wrote:
For system-wide gems, I do "sudo gem install <gem>". That works because I've restored /etc/gemrc so that it reads simply "gem:", instead of "gem: --user-install". I'm still not clear on why this configuration file is altered in the Arch package. I think it's because there's a feeling that system-wide gems should be handled by pacman, which I personally find weird.
That is not a feeling, gemrc is removed on purpose so that you _don't_ run "sudo gem". Your whole system is managed by pacman except for some dirs, why wreak havok in it by using some other package manager? I'm exagerating on purpose, I know rubygem does its job well and there shouldn't be conflicts bewteen the two, but it just doesn't feel right.
We're talking about two completely different domains that both happen to use the filesystem for storage. Ruby gems are not packages in the same sense that Firefox is a package. It's a different concept, and although I agree that Pacman could do an acceptable job of managing Ruby gems insofar as both systems bundle files for installation, it is not possible to map the two systems completely. They are built for different purposes, and have different semantics.
Agreed.
Yes, gem is easy to use, so is pacman. You can achieve the same results with pacman-handled ruby packages given some effort on the maintainer's part (apart maybe for the, imho unneeded, complexity of having multiple versions of the same gem, but that is another story).
To some extent, yes. You end up with a lowest-common-denominator situation. It's acceptable for casual use, I'm sure.
Yep, and that is sufficient for a lot of people. Developers are better off using rubygem/bundler/rbenv, I agree too.
When you start doing Ruby development, you quickly come to rely on Bundler, which relies on Rubygems. Throwing Pacman into the mix would cause a big mess, at least until you learn to use rbenv or something similar.
As I mentioned above, you can easily reverse that statement. Why throw Bundler and Rubygems in the mix when you have pacman? I personally think that having pacman-managed dirs tinkered with by another package manager is heresy :P I have no problem using one in "~" or any other dir that pacman does not manage though, and as Rashif said, all in all it's just a matter of options and preferences.
Based on that paragraph, I'd be surprised if you had undertaken any serious development in Ruby. Many Rails developers work on Macs (not to mention other flavours of Linux), and Rubygems and Bundler are cross-platform tools. Relying on Pacman for Ruby development would render a project pointlessly platform-dependent.
I have indeed never undertaken development in ruby, and as I said before, I only use a few ruby packages. However, you said it yourself, ruby and pacman both have different uses, my point was: do not change the content of a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't ever use both. In the end, we're free to do anything we want, I just think it is bad practice to mix things up like described above. In extreme cases, just have a look at Windows, where anybody can install anything anywhere, we all know what it ends up like :P
Paul
Cheers, -- Maxime
On Monday 13 Jan 2014 17:58:59 Maxime Gauduin wrote:
I only use a few ruby packages. However, you said it yourself, ruby and pacman both have different uses, my point was: do not change the content of a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't ever use both. In the end, we're free to do anything we want, I just think it is bad practice to mix things up like described above. In extreme cases, just have a look at Windows, where anybody can install anything anywhere, we all know what it ends up like :P
What worries me about this is that you're making a clear distinction between "users" and "developers". I'm not convinced that is really consistent with the Arch Way, which I have always admired because it expects that the line between users and developers is blurry, and actively encourages users to experiment and cross over. The idea of needing to "switch" to ruby's (purpose-built) method of handling gems when a user wants to achieve "developer" status seems wrong to me. And for what? sudo pacman -S ruby-json sudo pacman -R ruby-json instead of: sudo gem install json sudo gem uninstall json It doesn't seem worth it to me. The commands can easily be documented in the wiki, and then the bar is lowered that tiny bit more for hacking something together in Ruby. Bear in mind that rubygems doesn't spread files all over the system, either. They're kept neatly tucked out of the way in /usr/lib/ruby, except for a few wrappers that end up in /usr/bin so that they're in the PATH. Paul
On Tue, Jan 14, 2014 at 11:04 AM, Paul Gideon Dann <pdgiddie@gmail.com>wrote:
On Monday 13 Jan 2014 17:58:59 Maxime Gauduin wrote:
I only use a few ruby packages. However, you said it yourself, ruby and pacman both have different uses, my point was: do not change the content of a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't ever use both. In the end, we're free to do anything we want, I just think it is bad practice to mix things up like described above. In extreme cases, just have a look at Windows, where anybody can install anything anywhere, we all know what it ends up like :P
What worries me about this is that you're making a clear distinction between "users" and "developers". I'm not convinced that is really consistent with the Arch Way, which I have always admired because it expects that the line between users and developers is blurry, and actively encourages users to experiment and cross over. The idea of needing to "switch" to ruby's (purpose-built) method of handling gems when a user wants to achieve "developer" status seems wrong to me.
The Arch Way is not about encouraging you to be a developer, it is about leaving all the tools in your hands so that you can decide what you want to do with them. I don't have a problem making a distinction between users and developers, and clearly you are not dealing with users on a daily basis if you can't do the same :P I don't consider myself a developer, but I still make the most out of Arch Linux in my own way, which is, the Arch Way. There is no "typical" Arch user/developer, each person uses it differently for their own purpose, be it a server, home media center, gaming rig or a ruby hacking machine.
And for what?
sudo pacman -S ruby-json sudo pacman -R ruby-json
instead of:
sudo gem install json sudo gem uninstall json
It doesn't seem worth it to me. The commands can easily be documented in the wiki, and then the bar is lowered that tiny bit more for hacking something together in Ruby. Bear in mind that rubygems doesn't spread files all over the system, either. They're kept neatly tucked out of the way in /usr/lib/ruby, except for a few wrappers that end up in /usr/bin so that they're in the PATH.
Paul
It seems to me (maybe I'm wrong, but that's how it feels) you wish to force people to use rubygem instead of pacman, but I say it is not necessary if pacman is sufficient for their need. If you feel the need to do so, and I'm sure other people do, I'm just stating that in my opinion it is bad practice to interfere with pacman's ecosystem via another package manager, all the more if you give it root permissions. Now I understand you have a need for root permissions, and I won't insist , but keep in mind that gems can be installed anywhere outside pacman's jurisdiction and still be run as root. I know rubygem is not messy at all, I'm using it to repackage gems for pacman, still I think it is a good idea for most people to point it to a safe directory, and you always have the possibility to add the relevant dir to your PATH. As for multiple versions, the root of all evil is that there are too many gems that are not updated to support the latest version of a gem. Pacman does not have to deal with that because we make sure packages are always compatible with the latest and greatest, by submitting patches and/or bug reports upstream. That's one of the 2 reasons why rubygem can be a better choice for advanced ruby users, the other being the effort needed to repackage gems (which is not much, unless you have hundreds of them). Now I feel this discussion has dragged out for too long, and I believe I've made my point several times already, so I will take my leave and go back to my cave to geek to my heart's content :P Cheers, -- Maxime
On 14 January 2014 18:04, Paul Gideon Dann <pdgiddie@gmail.com> wrote:
They're kept neatly tucked out of the way in /usr/lib/ruby, except for a few wrappers that end up in /usr/bin so that they're in the PATH.
You use your system as you wish, but that is not recommended/supported practice. You can use other directories and still make them accessible system-wide. Heck, you can even have your home in system PATH. -- GPG/PGP ID: C0711BF1
On Mon, Jan 13, 2014 at 4:35 PM, Maxime Gauduin <alucryd@gmail.com> wrote:
As I mentioned above, you can easily reverse that statement. Why throw Bundler and Rubygems in the mix when you have pacman? I personally think that having pacman-managed dirs tinkered with by another package manager is heresy :P I have no problem using one in "~" or any other dir that pacman does not manage though, and as Rashif said, all in all it's just a matter of options and preferences.
Rubygems, as well as well as bundler, RVM and the rest of the Ruby ecosystem, use folders under $HOME by default (unless installing with sudo, which is not really necessary). There should be no pollution of pacman-managed dirs. I also think pacman packages for ruby gems, or even the Ruby interpreter itself, are wasted effort. The ruby community generally considers using system-managed gems and interpreters a bad practice; they get slower updates, it's hard to keep multiple versions installed in parallel, different users share the same set of gems which is not always desirable... I'm sure fixing all those in pacman packages is possible but it would be costly, and why do that work when there are tools in the Ruby ecosystem that already solve the problem in a platform-independent way? It seems to me like a case of "when you have a hammer, all problems look like nails". In this case pacman is not the best suited tool, rubygems and bundler and RVM and friends are. Just my 2 cents. ----------- I'd flash you my business card, but my hands are too full of guns. - Peter Quill, aka Star-Lord, making another dashing rescue
On Mon, Jan 13, 2014 at 12:33:30PM +0000, Paul Gideon Dann wrote:
On Monday 13 Jan 2014 12:59:28 Maxime Gauduin wrote:
IMHO, the reason why you would choose to use rubygem over pacman depends of how extensive a ruby user you are. I like to have gems handled by pacman, but I only use a few of them and don't need to have several versions of the same gem. Having them installed system-wise also makes them easily available to all users. That being said, you can achieve the same with rubygem by sharing a common ruby home between your users. As for the files not handled by pacman, home dirs are not referenced anyway so having gems in it really doesn't hurt.
For system-wide gems, I do "sudo gem install <gem>". That works because I've restored /etc/gemrc so that it reads simply "gem:", instead of "gem: --user-install". I'm still not clear on why this configuration file is altered in the Arch package. I think it's because there's a feeling that system-wide gems should be handled by pacman, which I personally find weird.
I get that people may be afraid of using a second package manager, but Rubygems is incredibly easy to use, and handles gems much more effectively than can be achieved in pacman, because Rubygems is domain-specific. A quick command reference on the Ruby page on the Wiki should be enough.
When you start doing Ruby development, you quickly come to rely on Bundler, which relies on Rubygems. Throwing Pacman into the mix would cause a big mess, at least until you learn to use rbenv or something similar.
Paul
There are 6 ruby gems I use regularly: - Jekyll - Kramdown, a Ruby markdown parser (which I use with Jekyll) - Nanoc - Middleman - Heroku - Haml - Sass Several of these gems have other Ruby dependencies, some of which are shared; however, some gems (in my case Jekyll and Middleman) depend on different versions of the same gems. rubygems is able to handle installation, upgrades and removal of multiple versions of the gems simultaneously; however, some time back I tried to use pacgem[1] to allow pacman to handle packaging and updates in a uniform manner, since it seemed more "Arch-like." That was how I discovered the multi-version dependencies: As pacman will only allow a single version of a package to be installed on the system at a given time, I was frequently alerted to "updates" of dependency gems I had installed. Middleman depends on a later version of a particular library than does Jekyll; if I update the gem via pacgem, Middleman will function, while Jekyll will break. It simply wasn't possible to use both simultaneously, and since I depend on Jekyll for work I do, that's unacceptable. It's far simpler (in my opinion) to use "gem install" as $USER to install to my /home directory and add the installation directory to $PATH, as I'm the only one who uses my machine. In the event that gems do (for whatever horrific reason) become unmanageable, one can simply nuke the directory where they're installed and reinstall all necessary gems rather quickly, without risk to the system at large. As a side note, since gems are by default distributed through the Ruby gems network, including them in the AUR essentially amounts to writing a PKGBUILD that serves as a wrapper to rubygems anyway. [1]: https://aur.archlinux.org/packages/pacgem/
On Monday 13 Jan 2014 11:03:32 Bigby James wrote:
That was how I discovered the multi-version dependencies: As pacman will only allow a single version of a package to be installed on the system at a given time, I was frequently alerted to "updates" of dependency gems I had installed. Middleman depends on a later version of a particular library than does Jekyll; if I update the gem via pacgem, Middleman will function, while Jekyll will break. It simply wasn't possible to use both simultaneously, and since I depend on Jekyll for work I do, that's unacceptable. It's far simpler (in my opinion) to use "gem install" as $USER to install to my /home directory and add the installation directory to $PATH, as I'm the only one who uses my machine. In the event that gems do (for whatever horrific reason) become unmanageable, one can simply nuke the directory where they're installed and reinstall all necessary gems rather quickly, without risk to the system at large.
Thanks, Bigby, for articulating the point far better than I was doing :) I'd like to add to this that I also use Ruby for general scripting and monitoring on several servers that I maintain, mostly through cron jobs. These small system scripts run as root. I could install the gems into /root, but I prefer to have them installed system-wide, as they're more visible that way (element of least surprise), and means I can write and test the scripts as non-root first. That's why I use "sudo gem install" to manage system gems, and why I remove the --user-install option in my /etc/gemrc. Paul
On 13 January 2014 18:52, Paul Gideon Dann <pdgiddie@gmail.com> wrote:
I'm not trying to dismiss your effort, I'm just concerned that this seems a little like duplication.
It's about options. You can experience the same thing with Python, R, Vim, etc. I have long given up using distribution packages for Vim, in order to keep my config somewhat portable. I deploy the same environment many times. For Python, I continue to use distribution packages because I haven't found the need to deploy the same environment several times, and many libs can have system deps and that by itself warrants a system-wide package manager. As for R, its use cases rarely require deep system-level interaction (you don't often write fancy apps with it) so its libs do not cause much trouble. Therefore, I keep it self-contained, as I do with Vim. -- GPG/PGP ID: C0711BF1
participants (9)
-
Alfredo Palhares
-
Anatol Pomozov
-
Bigby James
-
geralt＠gmail.com
-
Magnus Therning
-
Maxime Gauduin
-
Paul Gideon Dann
-
Rashif Ray Rahman
-
Simon Hanna