4 ms·

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 envir

by 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.

by maaku 14y ago

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.