9 ms·

Abandoning Rubygems

62 points by _pius 14y ago

zimbatm 14y ago
Good. Because of all the dependencies it would also make the Gemfile much harder to resolve and create unnecessary conflicts with the project anyways.
threedaymonk 14y ago
This is a sensible decision. 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.
- mattlong 14y ago
  pip. Always choose pip over easy_install. Waiting for someone to call me out for speaking in absolutes...
  - purephase 14y ago
    I voted you up in agreement if that makes you feel any better.
  - obviouslygreen 14y ago
    More specifically, use pip in conjunction with virtualenv and requirements files.
  - untothebreach 14y ago
    I would be surprised if there were many left in the Python community who would disagree with you.
andyl 14y ago
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.
- nigelk 14y ago
  We very much encourage people to use the package repositories we host: http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html http://docs.puppetlabs.com/guides/puppetlabs_package_reposit... Are you suggesting we should drop gem support entirely andyl?
  - damm 14y ago
    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
    - npsimons 14y ago
      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.
      - mattmanser 14y ago
        RubyGems works cross-platform?
Axsuul 14y ago
How do plugins work with this type of installation method? For example, https://github.com/mosaicxm/vagrant-hostmaster https://github.com/mosaicxm/vagrant-hostmaster depends on a certain version of a vagrant gem.
- mitchellh 14y ago
  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. Still, I do put some protection in place: https://github.com/mitchellh/vagrant-aws/blob/c88be9d243e0b9322f50e270118b669046626a4d/lib/vagrant-aws/plugin.rb#L1-L11 https://github.com/mitchellh/vagrant-aws/blob/c88be9d243e0b9...
gfunk911 14y ago
I know the tile is the title of the article, but it's very deceptive before you have the context
damm 14y ago
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, ...)
philwelch 14y ago
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.
- euroclydon 14y ago
  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.
  - philwelch 14y ago
    Developing on a Linux virt is good practice anyway. Best if it matches your production environment.
  - purephase 14y ago
    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).
    - rjacoby5 14y ago
      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...)
      - purephase 14y ago
        Oh, Windows is much, much worse. ;) I just wouldn't lay blame on Ruby/Python etc. communities for the vagaries and whims of OS shops.
delano 14y ago
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.
maaku 14y ago
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.
- mitchellh 14y ago
  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'm sorry, but this is the way forward.
anonfunction 14y ago
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.

62 points by _pius 14y ago

Good. Because of all the dependencies it would also make the Gemfile much harder to resolve and create unnecessary conflicts with the project anyways.

threedaymonk 14y ago

This is a sensible decision. 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.

mattlong 14y ago
pip. Always choose pip over easy_install. Waiting for someone to call me out for speaking in absolutes...
- purephase 14y ago
  I voted you up in agreement if that makes you feel any better.
- obviouslygreen 14y ago
  More specifically, use pip in conjunction with virtualenv and requirements files.
- untothebreach 14y ago
  I would be surprised if there were many left in the Python community who would disagree with you.

andyl 14y ago

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.

nigelk 14y ago
We very much encourage people to use the package repositories we host: http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html http://docs.puppetlabs.com/guides/puppetlabs_package_reposit... Are you suggesting we should drop gem support entirely andyl?
- damm 14y ago
  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
  - npsimons 14y ago
    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.
    - mattmanser 14y ago
      RubyGems works cross-platform?

Axsuul 14y ago

How do plugins work with this type of installation method? For example, https://github.com/mosaicxm/vagrant-hostmaster https://github.com/mosaicxm/vagrant-hostmaster depends on a certain version of a vagrant gem.

mitchellh 14y ago
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. Still, I do put some protection in place: https://github.com/mitchellh/vagrant-aws/blob/c88be9d243e0b9322f50e270118b669046626a4d/lib/vagrant-aws/plugin.rb#L1-L11 https://github.com/mitchellh/vagrant-aws/blob/c88be9d243e0b9...

gfunk911 14y ago

I know the tile is the title of the article, but it's very deceptive before you have the context

damm 14y ago

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, ...)

philwelch 14y ago

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.

euroclydon 14y ago
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.
- philwelch 14y ago
  Developing on a Linux virt is good practice anyway. Best if it matches your production environment.
- purephase 14y ago
  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).
  - rjacoby5 14y ago
    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...)
    - purephase 14y ago
      Oh, Windows is much, much worse. ;) I just wouldn't lay blame on Ruby/Python etc. communities for the vagaries and whims of OS shops.

delano 14y ago

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.

maaku 14y ago

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.

mitchellh 14y ago
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'm sorry, but this is the way forward.

anonfunction 14y ago

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.