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

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 Monday 13 Jan 2014 13:17:13 Magnus Therning wrote:

On Mon, Jan 13, 2014 at 11:45 AM, Simon Hanna 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 Mon, Jan 13, 2014 at 11:52 AM, Paul Gideon Dann 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 Mon, Jan 13, 2014 at 1:33 PM, Paul Gideon Dann 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 Mon, Jan 13, 2014 at 5:32 PM, Paul Gideon Dann 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 Tue, Jan 14, 2014 at 11:04 AM, Paul Gideon Dann 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 Mon, Jan 13, 2014 at 4:35 PM, Maxime Gauduin 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 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