I work with Ruby daily, so using RubyGems to install a package is easy for me. On the other hand, when I find the installation instructions for a tool written in Python, I'm often confused: there will be a couple of options for installation, and I don't even know whether I've got pip or easy-install, let alone which of them I should choose!
There are downsides, however: the author now has to take on responsibility for building packages for multiple platforms and architectures.
I recently switched to Vagrant Installers. Mitchell has done a nice job of isolating the Vagrant environment. The installer and Vagrant plugins work great, and it's a win to remove the Vagrant dependency from my project Gemfile.
Ruby-based 'infrastructure' tools should consider following Vagrant's lead. I'm looking at you, Puppet.
Gems are the most confusing thing to new Ruby users.
Example that most people on HN will likely get, but most people in real life will ask you why? They have a point you should pay attention to.
If you read most ruby books you'll get one of two patterns.
1. Install brew
2. Install libyaml in brew
3. Install rvm
4. Install ruby in rvm linked to libyaml
5. gem install x and if you need y... just get another gem that supports it.
One of the core problems I've seen is most people do not grasp that a 'gem' is a package. After looking over some of the gems published to Rubygems they quickly realize the quality differs and they are at their own mercy.
Now ask yourself, why would anyone who wants their product to be (useful|used) condone this?
Basically it's a slippery slope, I understand both sides of the coin and I don't know what to say shrug
I'll be perfectly honest, as a Debian user/admin, I've never really saw the point of Gems. They just seem like Yet Another NIH unnecessary package format.
This is the classic operating-system package management/programming-language library packaging dichotomy. You see the same conflict of philosophies with Perl and CPAN packages versus Red Hat / CentOS .rpms of the same package.
Sysadmins frequently seem to like the operating-system approach. Developers frequently seem to like the programming-language approach.
More honesty, my original composition was a bit more inflammatory, but I do (sort of) understand where the urge to package comes from. I've been someone who's pulled things quickly together, whether it be through CPAN or the incredibly convoluted checkout-build scripts of ROS (http://ros.org), and yes, very often I will clone and build things from GitHub, cause dangit, it's not packaged yet.
But I've come also from the dependency hell that was GNOME on RedHat over a decade ago, and I just love the fact that I can almost always type "apt-get install $name_of_new_toy" and be playing with it in under five minutes, all without having to worry about breaking other packages or strewing files god-knows-where, or having multiple, redundant, possibly bug and security hole ridden copies of dependencies, and knowing that I can deploy it instantly on my web server. Windows and OSX also don't figure very much into my worldview, so I don't really care much that they need bolted on package managers to fix their brokenness.
Seriously, why even bother posting? Your view and your original question is totally worthless as it turns out you're an OS-bigot. We work in a world of logic peppered by pockets of irrational fan-boys. Is it fear of the unknown that drives you to such extreme statements?
You would do much better if you just reviled them all equally as I do. Windows is shit. Macs are shit. Linux is shit. All programming languages are shit. Though I profess a special hatred for javaschipt. That's built its own little corner of hell. Computers are items of vast wasted potential covered in liberal amounts of poorly implemented shit.
And the best we can do for the next 50 years is mine it and clear it gradually away as we uncover the occasional nugget of gold in festering piles of, well, you know what.
I think this is because most developers haven't (yet) been paged at 3 AM to discover that everything is fucked because a handful of critical servers somehow still have bugs in libraries that were already fixed. I'm a developer and I think language-specific package ghettos are a pretty crazy way to handle deployment to production. Any dependency I can't express in the same way as all the others (namely my platform's one and only package manager) is a ticking bomb.
So on the latest version of Ubuntu (12.10), if I run "apt-get install rails" I get Rails 2.3. That was originally released over 4 years ago. There have been (nearly) 4 major releases since then. How do you work around that, or do you not?
nigelk - yes, it think using Package Repos exclusively would be a win for Puppet. Fewer install options to confuse new users, simpler support model for your developers.
BTW I do use your repositories. For me, they have proven to be more reliable than the Gem install.
One of the things I like about Vagrant's installer is that he packages an embedded ruby version and installs it at /opt/vagrant/embedded. Vagrant plugins are installed at /opt/vagrant/embedded/gems. (using 'vagrant gem') This is sweet, because the whole Vagrant environment is isolated from the rest of the system.
By contrast, the Puppet installer depends on a system ruby. It puts ruby 1.8.7 on my path, which I don't want. Then I've got to take special effort not to use it or corrupt it. Yukk.
So if I were King - Puppet would use Package Repos exclusively, and depend on its own isolated/embedded Ruby.
We're thinking very much about the direction of embedding all dependencies, but we're also conscious of the needs of the Linux distros, who don't package software that way.
There is a downside to having all your apps embed their dependencies. It becomes significantly more complicated to update libraries in response to vulnerabilities and bugs.
Vagrant 1.1 introduced a new plugin system where you no longer make your plugins (which happen to be RubyGems) depend on Vagrant itself as a gem. You assume Vagrant will load it into its own environment so you write according to the Vagrant API and it will work.
Unfortunately not very shocking, the move to packing up ruby with your application so it's easier to setup isn't new (many projects have done this, chef, sensu, ...)
Rubygems is good for Ruby libraries and little else. It's like CPAN for Ruby. Once you're distributing software to users with heterogeneous dependencies (i.e. not all your dependencies are other libraries written in the same language), tools like Rubygems and CPAN are a bad fit.
That was one of the things that drove me away from Ruby. Using a mac, I tried to install gems for some robust graphics capabilities and was pretty surprised to get errors related to C/C++ compiles. It doesn't help that it was so torturous for me to get GCC and CLANG both enabled and switchable on OSX. I just could not track down the make calls in the gems that kept choosing the wrong compiler.
I may go back, but I'll do all my development on a virtual linux machine.
I'd put this particular failure more in Apple's camp then Ruby. You would have similar issues with almost any other language and environment.
The simple fact that you need Xcode's SDK and homebrew/macports on a machine to get anything done outside of Xcode speaks volumes for using Mac's as development workstations (or, specifically, MacOS).
Agreed that this is a pain, but _much_ less so than getting a working compiler/paths/libs/etc on Windows for doing Ruby work. (Unless you go with an all-in-one installer...)
>The simple fact that you need Xcode's SDK and homebrew/macports on a machine to get anything done outside of Xcode speaks volumes for using Mac's as development workstations (or, specifically, MacOS).
What does that even mean (besides being incorrect)?
How is the situation different in, say, Windows? Can you compile C/C++ stuff out of the box?
Or Linux, for that matter. In a lot of distros, gcc, make and co have to be installed -- they are not part of the default install.
As for the incorrect part: you don't need XCode. You can just install the "command line tools" package from Apple, that contains compilers, headers etc.
For me, the worst part was having gxx symlinked to clang. What happened was, the first time I had to compile software that needed real gxx, I went fiddling with paths and symlinks to get that software working. Then, months later, I had to compile something that needed clang, so I fiddled some more, and just for kicks, tried to keep track, so I could compile the original software that required gxx. That all worked fine, if painful and time consuming.
Later, I was surprised to find the Ruby Gems use gxx, make, and autoconf. I thought it was a pure Ruby code package manager, that would just tell me to install some native library if it wasn't there, but no, it wants to download and build for itself using gxx.
Your comment is one of my least favorite parts of HN. You read your own bias into my comment. I said:
"You would have similar issues with almost any other language and environment."
This includes Linux, Windows etc. I singled out MacOS as it was relevant to the parent comment. And, as for "incorrect", I think "command-line tools" and SDK could likely be used interchangeably in this context and saying otherwise is splitting hairs.
Part of the problem is that providing pre-compiled gems is a HUGE pain for developers. The gemspec's 'platform' strings change every now and then, so a gem precompiled and published with Rubygems 1.x will not be found by Rubygems 2.x etc...
The rake-compiler project tries to address this, but at this point I'm not sure if I am any better off than people who waste their lifetime in autoconf hell.
Packaging systems that are not language specific were created to solve this exact problem. Making the switch is a sensible decision that has nothing to do with Rubygems.
Your project is maturing which is great. There's no need to throw the technology that helped get you there under the bus.
No. This is a massive step backwards: please reconsider.
At my own company we use vagrant for developer environments. And we do so using per-project ruby environments and bundled dependencies. Setting up a new developer is as simple as a git clone followed by running make. It works on every platform and requires ZERO system dependencies.
I understand the reasoning. I understand that most people should be using the installers not the gems. But is it really that hard to package a gem for each release and just throw a warning on it?
PS: Someone change the title from "Abandoning Rubygems" to "Vagrant no longer distributed by rubygem" or somesuch.
I'm sorry, I realize that for people who used Bundler for distributing Vagrant that this is an inconvenience.
Unfortunately, I strongly believe that using Bundler to distribute something like Vagrant is wrong. Do you use (or want to use) Bundler to distribute git? How do your developers install git? (or whatever VCS you use). No, you don't.
In that same spirit, Vagrant can be installed separately just as part of the dev machine setup process. An argument could be made here that you want a specific version, but I've worked very hard to maintain backwards compatibility and stability for this exact reason. Even if you're using V1 Vagarntfiles, Vagrant 1.1 works fine. The new Vagrant plugin system avoids plugin issues, as well.
Also, it wouldn't be hard to change that _make_ command to just install Vagrant, it doesn't need to be Bundler.
Maintaining a gem release ALONGSIDE a package release is not simple. I replaced pure-ruby tar with bsdtar. If I maintained both releases, I'd have to maintain both code paths. Or I'd have to throw an error if bsdtar is missing, which is not user friendly. Imagine gem installing and then running Vagrant and Vagrant says "You need bsdtar." Okayyyyy so you install bsdtar. Then it says "You need curl." Okayyyyy so you install curl. Then it says "You need libssh." At this point you're probably like "man, screw this." Installers avoid this entire issue. Bundler can't encapsulate this kind of dependency information.
I hardly ever use Rubygems, but decided to read anyways because I'm just now getting into using package managers and wanted to learn the reasoning for this choice.
Then I realized this was about Vagrant. I use Vagrant A LOT, and although I never had problems, I did find a lot of other people who had run into issues. This change will allow me to suggest Vagrant to my friends and colleagues with more faith.
43 comments
[ 4.9 ms ] story [ 101 ms ] threadI work with Ruby daily, so using RubyGems to install a package is easy for me. On the other hand, when I find the installation instructions for a tool written in Python, I'm often confused: there will be a couple of options for installation, and I don't even know whether I've got pip or easy-install, let alone which of them I should choose!
There are downsides, however: the author now has to take on responsibility for building packages for multiple platforms and architectures.
Ruby-based 'infrastructure' tools should consider following Vagrant's lead. I'm looking at you, Puppet.
http://docs.puppetlabs.com/guides/puppetlabs_package_reposit...
Are you suggesting we should drop gem support entirely andyl?
Example that most people on HN will likely get, but most people in real life will ask you why? They have a point you should pay attention to.
If you read most ruby books you'll get one of two patterns.
1. Install brew 2. Install libyaml in brew 3. Install rvm 4. Install ruby in rvm linked to libyaml 5. gem install x and if you need y... just get another gem that supports it.
One of the core problems I've seen is most people do not grasp that a 'gem' is a package. After looking over some of the gems published to Rubygems they quickly realize the quality differs and they are at their own mercy.
Now ask yourself, why would anyone who wants their product to be (useful|used) condone this?
Basically it's a slippery slope, I understand both sides of the coin and I don't know what to say shrug
Sysadmins frequently seem to like the operating-system approach. Developers frequently seem to like the programming-language approach.
But I've come also from the dependency hell that was GNOME on RedHat over a decade ago, and I just love the fact that I can almost always type "apt-get install $name_of_new_toy" and be playing with it in under five minutes, all without having to worry about breaking other packages or strewing files god-knows-where, or having multiple, redundant, possibly bug and security hole ridden copies of dependencies, and knowing that I can deploy it instantly on my web server. Windows and OSX also don't figure very much into my worldview, so I don't really care much that they need bolted on package managers to fix their brokenness.
Seriously, why even bother posting? Your view and your original question is totally worthless as it turns out you're an OS-bigot. We work in a world of logic peppered by pockets of irrational fan-boys. Is it fear of the unknown that drives you to such extreme statements?
You would do much better if you just reviled them all equally as I do. Windows is shit. Macs are shit. Linux is shit. All programming languages are shit. Though I profess a special hatred for javaschipt. That's built its own little corner of hell. Computers are items of vast wasted potential covered in liberal amounts of poorly implemented shit.
And the best we can do for the next 50 years is mine it and clear it gradually away as we uncover the occasional nugget of gold in festering piles of, well, you know what.
Although for just installing rails, using rubygems is the way to go, IMHO.
BTW I do use your repositories. For me, they have proven to be more reliable than the Gem install.
One of the things I like about Vagrant's installer is that he packages an embedded ruby version and installs it at /opt/vagrant/embedded. Vagrant plugins are installed at /opt/vagrant/embedded/gems. (using 'vagrant gem') This is sweet, because the whole Vagrant environment is isolated from the rest of the system.
By contrast, the Puppet installer depends on a system ruby. It puts ruby 1.8.7 on my path, which I don't want. Then I've got to take special effort not to use it or corrupt it. Yukk.
So if I were King - Puppet would use Package Repos exclusively, and depend on its own isolated/embedded Ruby.
We're thinking very much about the direction of embedding all dependencies, but we're also conscious of the needs of the Linux distros, who don't package software that way.
There is a downside to having all your apps embed their dependencies. It becomes significantly more complicated to update libraries in response to vulnerabilities and bugs.
But - it works! (my dev platform is Ubuntu 12.04)
Perhaps you don't need to embed all dependencies - just Ruby.
Good luck in thinking this thru!
Still, I do put some protection in place:
https://github.com/mitchellh/vagrant-aws/blob/c88be9d243e0b9...
I may go back, but I'll do all my development on a virtual linux machine.
The simple fact that you need Xcode's SDK and homebrew/macports on a machine to get anything done outside of Xcode speaks volumes for using Mac's as development workstations (or, specifically, MacOS).
What does that even mean (besides being incorrect)?
How is the situation different in, say, Windows? Can you compile C/C++ stuff out of the box?
Or Linux, for that matter. In a lot of distros, gcc, make and co have to be installed -- they are not part of the default install.
As for the incorrect part: you don't need XCode. You can just install the "command line tools" package from Apple, that contains compilers, headers etc.
Later, I was surprised to find the Ruby Gems use gxx, make, and autoconf. I thought it was a pure Ruby code package manager, that would just tell me to install some native library if it wasn't there, but no, it wants to download and build for itself using gxx.
"You would have similar issues with almost any other language and environment."
This includes Linux, Windows etc. I singled out MacOS as it was relevant to the parent comment. And, as for "incorrect", I think "command-line tools" and SDK could likely be used interchangeably in this context and saying otherwise is splitting hairs.
The rake-compiler project tries to address this, but at this point I'm not sure if I am any better off than people who waste their lifetime in autoconf hell.
Your project is maturing which is great. There's no need to throw the technology that helped get you there under the bus.
At my own company we use vagrant for developer environments. And we do so using per-project ruby environments and bundled dependencies. Setting up a new developer is as simple as a git clone followed by running make. It works on every platform and requires ZERO system dependencies.
I understand the reasoning. I understand that most people should be using the installers not the gems. But is it really that hard to package a gem for each release and just throw a warning on it?
PS: Someone change the title from "Abandoning Rubygems" to "Vagrant no longer distributed by rubygem" or somesuch.
Unfortunately, I strongly believe that using Bundler to distribute something like Vagrant is wrong. Do you use (or want to use) Bundler to distribute git? How do your developers install git? (or whatever VCS you use). No, you don't.
In that same spirit, Vagrant can be installed separately just as part of the dev machine setup process. An argument could be made here that you want a specific version, but I've worked very hard to maintain backwards compatibility and stability for this exact reason. Even if you're using V1 Vagarntfiles, Vagrant 1.1 works fine. The new Vagrant plugin system avoids plugin issues, as well.
Also, it wouldn't be hard to change that _make_ command to just install Vagrant, it doesn't need to be Bundler.
Maintaining a gem release ALONGSIDE a package release is not simple. I replaced pure-ruby tar with bsdtar. If I maintained both releases, I'd have to maintain both code paths. Or I'd have to throw an error if bsdtar is missing, which is not user friendly. Imagine gem installing and then running Vagrant and Vagrant says "You need bsdtar." Okayyyyy so you install bsdtar. Then it says "You need curl." Okayyyyy so you install curl. Then it says "You need libssh." At this point you're probably like "man, screw this." Installers avoid this entire issue. Bundler can't encapsulate this kind of dependency information.
I'm sorry, but this is the way forward.
Then I realized this was about Vagrant. I use Vagrant A LOT, and although I never had problems, I did find a lot of other people who had run into issues. This change will allow me to suggest Vagrant to my friends and colleagues with more faith.