Notice: Vagrant 1.1+ will no longer distribute as RubyGems. Packages only.
1,500 views
Skip to first unread message
Mitchell Hashimoto
Jun 14, 2012, 12:31:46 AM6/14/12
to vagra...@googlegroups.com
Hello all,
I've come to the decision that starting with Vagrant 1.1 and for the
ongoing future, Vagrant will cease to be distributed as a RubyGem.
Vagrant 1.0.x will continue to be backported to both installers and
RubyGem releases. Additionally, I'll push a 1.0.x update at some point
to notify users that updated versions are available only as
installers.
This has always been the plan, and I released Vagrant 1.0 as both a
gem and installers because the entire 0.x series were gems and because
the installers were beta. Over the past few months, many issues have
been identified and fixed with the installers. Today, the installers
very stable.
However, I'd still like to share the reasons for the change:
* RubyGems is prone to many environmental variables: Ruby version,
paths, permissions (sudo or no sudo?), RVM, etc. This actually leads
to a lot of strange issues. Installers allow me to tightly control the
environment that Vagrant runs in and therefore minimize the issues
caused due to external forces. This results in a much better
experience overall for users.
* Over the next few releases, I'll introduce some new library
requirements (such as libssh2), and installers will let me package
them with Vagrant, rather than adding a pre-requisite for users to
install the library, since library installs can be a nightmare on some
systems such as Windows, and this way I also control the version.
* Too many people still see Vagrant as just a "ruby thing," and I
think installers will get rid of this mindset, as it becomes more of a
downloaded and installed tool where the implementation language
doesn't much matter.
Of course, I know that people do have some concerns with this change,
which I'll address below.
First, I know many people add "vagrant" as a dependency in their
Bundler `Gemfile`. I've said it before and I still stand by my
viewpoint that this shouldn't be done. Vagrant shouldn't be considered
a Ruby library, it should be considered a tool like `git`. Therefore,
I don't think its too much to ask (especially with the ease of the
installers) for users to install this prior to using your project.
Next, a lot of people liked RubyGems because it does give you update
functionality. With packages, the only way to get updates is to
manually check the website, listen to the mailing list, etc. for a new
release. This issue is valid and I will be adding upgrade checking
abilities to Vagrant in the future, something similar to a `vagrant
update` command. Initially, this will only notify you of a new
release, but in the future I hope this can also auto-update for you.
Finally, another feature is that your platform may not be supported by
the packages or installers! Please let me know if this is the case and
I will attempt to create packages for your platform. Otherwise, I plan
on simply documenting how Vagrant can be built for alternate
platforms, and will expect users to build the software manually. This
is not unlike projects like `git`.
Please voice any concerns here before this takes effect and I will
address them as well as I can.
Best,
Mitchell
I've come to the decision that starting with Vagrant 1.1 and for the
ongoing future, Vagrant will cease to be distributed as a RubyGem.
Vagrant 1.0.x will continue to be backported to both installers and
RubyGem releases. Additionally, I'll push a 1.0.x update at some point
to notify users that updated versions are available only as
installers.
This has always been the plan, and I released Vagrant 1.0 as both a
gem and installers because the entire 0.x series were gems and because
the installers were beta. Over the past few months, many issues have
been identified and fixed with the installers. Today, the installers
very stable.
However, I'd still like to share the reasons for the change:
* RubyGems is prone to many environmental variables: Ruby version,
paths, permissions (sudo or no sudo?), RVM, etc. This actually leads
to a lot of strange issues. Installers allow me to tightly control the
environment that Vagrant runs in and therefore minimize the issues
caused due to external forces. This results in a much better
experience overall for users.
* Over the next few releases, I'll introduce some new library
requirements (such as libssh2), and installers will let me package
them with Vagrant, rather than adding a pre-requisite for users to
install the library, since library installs can be a nightmare on some
systems such as Windows, and this way I also control the version.
* Too many people still see Vagrant as just a "ruby thing," and I
think installers will get rid of this mindset, as it becomes more of a
downloaded and installed tool where the implementation language
doesn't much matter.
Of course, I know that people do have some concerns with this change,
which I'll address below.
First, I know many people add "vagrant" as a dependency in their
Bundler `Gemfile`. I've said it before and I still stand by my
viewpoint that this shouldn't be done. Vagrant shouldn't be considered
a Ruby library, it should be considered a tool like `git`. Therefore,
I don't think its too much to ask (especially with the ease of the
installers) for users to install this prior to using your project.
Next, a lot of people liked RubyGems because it does give you update
functionality. With packages, the only way to get updates is to
manually check the website, listen to the mailing list, etc. for a new
release. This issue is valid and I will be adding upgrade checking
abilities to Vagrant in the future, something similar to a `vagrant
update` command. Initially, this will only notify you of a new
release, but in the future I hope this can also auto-update for you.
Finally, another feature is that your platform may not be supported by
the packages or installers! Please let me know if this is the case and
I will attempt to create packages for your platform. Otherwise, I plan
on simply documenting how Vagrant can be built for alternate
platforms, and will expect users to build the software manually. This
is not unlike projects like `git`.
Please voice any concerns here before this takes effect and I will
address them as well as I can.
Best,
Mitchell
Florian Gilcher
Jun 14, 2012, 3:14:21 AM6/14/12
to vagra...@googlegroups.com
Hi Mitchell,
I am definitely in favor of making installers the default installation[1] and letting _users_ ignore whats inside. Virtualbox has to be installed anyways, so the second install process doesn't hurt.
But this is also making life harder for people that use multiple vagrant versions, for example for vagrant/plugin development. While most plugins are not tested automatically (including mine), we will soon have 2 versions of vagrant that are actively maintained and differ in several aspects. Testing by hand against one version was somewhat manageable, but cross-testing against 2 versions calls for automated or at least supporting approaches. Now, when developing a plugin, we are in Rubyland anyways, so hiding doesn't make much sense and Ruby has a lot of support for all that _if you are using gems_. Now, it would be possible to replicate all that in vagrant (vagrant SDK, maybe?), but I don't feel it is worth it. So a rubygems fallback for development mode would be nice.
As a user, I enjoy that installers won. As a plugin developer, not so much.
Regards,
Florian
[1]: and, while we're at it, could we introduce "vagrant plugin install" as an alias to "vagrant gem install vagrant-$1" if not done already? Didn't check...
Ian Chilton
Jun 14, 2012, 9:37:29 AM6/14/12
to vagra...@googlegroups.com
Hi Florian,
Good point about the installs - Virtualbox has to be done with an
installer, so it makes sense to install Vagrant with one afterwards
(and as Mitchell) says, it is more of an app than a library/gem.
With regards to your second point though, surely if the user is savvy
enough to be writing plugins for Vagrant, wouldn't they be able to be
able to run outside of the installer using the source, build their own
gem from it etc?
Ian
Good point about the installs - Virtualbox has to be done with an
installer, so it makes sense to install Vagrant with one afterwards
(and as Mitchell) says, it is more of an app than a library/gem.
With regards to your second point though, surely if the user is savvy
enough to be writing plugins for Vagrant, wouldn't they be able to be
able to run outside of the installer using the source, build their own
gem from it etc?
Ian
Mitchell Hashimoto
Jun 14, 2012, 1:47:57 PM6/14/12
to vagra...@googlegroups.com
Florian,
On Thu, Jun 14, 2012 at 12:14 AM, Florian Gilcher <f...@andersground.net> wrote:
> Hi Mitchell,
>
> I am definitely in favor of making installers the default installation[1]
> and letting _users_ ignore whats inside. Virtualbox has to be installed
> anyways, so the second install process doesn't hurt.
>
> But this is also making life harder for people that use multiple vagrant
> versions, for example for vagrant/plugin development. While most plugins are
> not tested automatically (including mine), we will soon have 2 versions of
> vagrant that are actively maintained and differ in several aspects. Testing
> by hand against one version was somewhat manageable, but cross-testing
> against 2 versions calls for automated or at least supporting approaches.
> Now, when developing a plugin, we are in Rubyland anyways, so hiding doesn't
> make much sense and Ruby has a lot of support for all that _if you are using
> gems_. Now, it would be possible to replicate all that in vagrant (vagrant
> SDK, maybe?), but I don't feel it is worth it. So a rubygems fallback for
> development mode would be nice.
This is a great point. I actually think the best thing here would be
to install Vagrant to different locations or in a chroot environment.
There is no better way to develop a plugin than versus what will
actually be installed. Plus, you should be able to install separate
versions and since they're isolated they'll just work well together.
That being said, I don't think the installers (except Windows) provide
any easy way to go into other directories. The linux packages are
probably fine too. I just need to take a look at Mac OS X.
Does this make sense? If not, what workflow were you imagining?
>
> As a user, I enjoy that installers won. As a plugin developer, not so much.
>
> Regards,
> Florian
>
> [1]: and, while we're at it, could we introduce "vagrant plugin install" as
> an alias to "vagrant gem install vagrant-$1" if not done already? Didn't
> check...
Definitely on the todo. I want to remove the "gem" concept out of
Vagrant as well. Plugins will still be RubyGems for now but I want to
buffer users from realizing that is what is going on.
Best,
Mitchell
On Thu, Jun 14, 2012 at 12:14 AM, Florian Gilcher <f...@andersground.net> wrote:
> Hi Mitchell,
>
> I am definitely in favor of making installers the default installation[1]
> and letting _users_ ignore whats inside. Virtualbox has to be installed
> anyways, so the second install process doesn't hurt.
>
> But this is also making life harder for people that use multiple vagrant
> versions, for example for vagrant/plugin development. While most plugins are
> not tested automatically (including mine), we will soon have 2 versions of
> vagrant that are actively maintained and differ in several aspects. Testing
> by hand against one version was somewhat manageable, but cross-testing
> against 2 versions calls for automated or at least supporting approaches.
> Now, when developing a plugin, we are in Rubyland anyways, so hiding doesn't
> make much sense and Ruby has a lot of support for all that _if you are using
> gems_. Now, it would be possible to replicate all that in vagrant (vagrant
> SDK, maybe?), but I don't feel it is worth it. So a rubygems fallback for
> development mode would be nice.
to install Vagrant to different locations or in a chroot environment.
There is no better way to develop a plugin than versus what will
actually be installed. Plus, you should be able to install separate
versions and since they're isolated they'll just work well together.
That being said, I don't think the installers (except Windows) provide
any easy way to go into other directories. The linux packages are
probably fine too. I just need to take a look at Mac OS X.
Does this make sense? If not, what workflow were you imagining?
>
> As a user, I enjoy that installers won. As a plugin developer, not so much.
>
> Regards,
> Florian
>
> [1]: and, while we're at it, could we introduce "vagrant plugin install" as
> an alias to "vagrant gem install vagrant-$1" if not done already? Didn't
> check...
Vagrant as well. Plugins will still be RubyGems for now but I want to
buffer users from realizing that is what is going on.
Best,
Mitchell
Luke Patterson
Jun 14, 2012, 2:55:21 PM6/14/12
to vagra...@googlegroups.com
So I take it there isn't much demand for embedding Vagrant? i.e. coding to Vagrant as a library, from an enclosing build tool
-- from mobile device with tiny keyboard, please excuse terseness and typos
Mitchell Hashimoto
Jun 14, 2012, 3:09:22 PM6/14/12
to vagra...@googlegroups.com
Luke,
On Thu, Jun 14, 2012 at 11:55 AM, Luke Patterson
<lukewpa...@gmail.com> wrote:
> So I take it there isn't much demand for embedding Vagrant? i.e. coding to
> Vagrant as a library, from an enclosing build tool
Great point. This is a very small use case of Vagrant in the grand
scheme of things, but it is still a use case. Through this method, it
won't be possible to script it directly as before, but it is still
possible using the new plugin interface coming with Vagrant 1.1. The
new plugin interface makes it very easy to add ad-hoc commands and
behaviors to Vagrant, and any build tools can simply register a plugin
with Vagrant and invoke what they want in order to get certain
behaviors.
I'll make sure that this is well documented.
Best,
Mitchell
On Thu, Jun 14, 2012 at 11:55 AM, Luke Patterson
<lukewpa...@gmail.com> wrote:
> So I take it there isn't much demand for embedding Vagrant? i.e. coding to
> Vagrant as a library, from an enclosing build tool
scheme of things, but it is still a use case. Through this method, it
won't be possible to script it directly as before, but it is still
possible using the new plugin interface coming with Vagrant 1.1. The
new plugin interface makes it very easy to add ad-hoc commands and
behaviors to Vagrant, and any build tools can simply register a plugin
with Vagrant and invoke what they want in order to get certain
behaviors.
I'll make sure that this is well documented.
Best,
Mitchell
Luke Patterson
Jun 14, 2012, 3:33:43 PM6/14/12
to vagra...@googlegroups.com
1.1 sounds nice. One option to help library-style consumers is a cli arg that allows an isolated gem repo. Need to get to a real keyboard to create feature request.
-- from mobile device with tiny keyboard, please excuse terseness and typos
shane knapp ☠
Jun 14, 2012, 8:48:38 PM6/14/12
to vagra...@googlegroups.com
+1 for packages as well. thanks for the update, mitch. we're moving
to vagrant at my company and were up in arms about "tool" vs.
"gemset". this thread cleared up all questions and concerns we had.
:)
shane
On Thu, Jun 14, 2012 at 2:13 PM, Tony Burns <tabo...@gmail.com> wrote:
> +1 for packages only
to vagrant at my company and were up in arms about "tool" vs.
"gemset". this thread cleared up all questions and concerns we had.
:)
shane
On Thu, Jun 14, 2012 at 2:13 PM, Tony Burns <tabo...@gmail.com> wrote:
> +1 for packages only
Florian Gilcher
Jun 16, 2012, 12:02:18 PM6/16/12
to vagra...@googlegroups.com
For cross-library-testing, I often use Appraisals:
which is basically a system to manage multiple Gemfiles with differing dependencies. But this depends on having a gem. I am not sure whether multiple installations is really a good way to solving things, as it would imply the need to writing tooling to detect all those dependencies.
My favorite solution would actually be to still release a gem, but remove it from the download page. Also, stick a big notice on it that this version is not meant for end-users.
Regards,
Florian
Mitchell Hashimoto
Jun 17, 2012, 11:26:10 PM6/17/12
to vagra...@googlegroups.com
Florian,
Yes, I understand why you would want this. This will continue to work
fine for now, since building the gem is quite easy from the source
repo.
My main concern is in the future if the dependencies get rather
complicated, then maintaining multiple gem-installed versions may
become quite a nightmare for a plugin developer. For example, what if
two versions of Vagrant depended on different (non-compatible)
versions of "libssh" ? That'd be quite a hard thing to maintain from a
gem perspective. But if you had two chrooted installs then this would
be an easy thing to maintain.
But, for the time being, gem installs from the source repo will remain
an easy thing. :)
Best,
Mitchell
>
> Regards,
> Florian
fine for now, since building the gem is quite easy from the source
repo.
My main concern is in the future if the dependencies get rather
complicated, then maintaining multiple gem-installed versions may
become quite a nightmare for a plugin developer. For example, what if
two versions of Vagrant depended on different (non-compatible)
versions of "libssh" ? That'd be quite a hard thing to maintain from a
gem perspective. But if you had two chrooted installs then this would
be an easy thing to maintain.
But, for the time being, gem installs from the source repo will remain
an easy thing. :)
Best,
Mitchell
>
> Regards,
> Florian
Mitchell Hashimoto
Jul 10, 2012, 1:11:09 PM7/10/12
to vagra...@googlegroups.com
Nathan,
On Tue, Jul 10, 2012 at 4:54 AM, Nathan Kleyn <ma...@unfinitydesign.com> wrote:
> Hey Mitchell,
>
> The big issue I have with this going forward is that it is a very common
> workflow for people to submit patches/pull requests to Vagrant and use their
> own git repo while they wait for it to be accepted/rejected. What happens if
> that patch gets rejected, but it's something necessary for the user? As the
> repo has the gemspec in it at present, adding their fork of Vagrant as a
> dependency is as simple as listing it in the Gemfile for most people. I fear
> that making it packages only will make this workflow very difficult.
I can see your concern here. As you might expect, I _very_ often run
from git. Because of this, the git-based install will remain very
easily possible. I haven't thought of it much but I'll make sure that
this is possible.
Best,
Mitchell
>
> As an example, I posted this pull request:
> https://github.com/mitchellh/vagrant/pull/995. This may or may not be
> something you guys want to pull into the main Vagrant repository, but for
> the setup we're maintaining this is a necessary patch for us. Not simply
> being able to distribute from the Git repository as a gem would make things
> like this extremely difficult, not least of all if you guys go down the
> auto-update route.
>
> On the whole, I do think packages are a necessary way forward for Vagrant,
> but I don't believe this should be at the sacrifice of the gem version.
>
> Nathan
On Tue, Jul 10, 2012 at 4:54 AM, Nathan Kleyn <ma...@unfinitydesign.com> wrote:
> Hey Mitchell,
>
> The big issue I have with this going forward is that it is a very common
> workflow for people to submit patches/pull requests to Vagrant and use their
> own git repo while they wait for it to be accepted/rejected. What happens if
> that patch gets rejected, but it's something necessary for the user? As the
> repo has the gemspec in it at present, adding their fork of Vagrant as a
> dependency is as simple as listing it in the Gemfile for most people. I fear
> that making it packages only will make this workflow very difficult.
I can see your concern here. As you might expect, I _very_ often run
from git. Because of this, the git-based install will remain very
easily possible. I haven't thought of it much but I'll make sure that
this is possible.
Best,
Mitchell
>
> As an example, I posted this pull request:
> https://github.com/mitchellh/vagrant/pull/995. This may or may not be
> something you guys want to pull into the main Vagrant repository, but for
> the setup we're maintaining this is a necessary patch for us. Not simply
> being able to distribute from the Git repository as a gem would make things
> like this extremely difficult, not least of all if you guys go down the
> auto-update route.
>
> On the whole, I do think packages are a necessary way forward for Vagrant,
> but I don't believe this should be at the sacrifice of the gem version.
>
> Nathan
Mitchell Hashimoto
Apr 30, 2013, 12:28:20 PM4/30/13
to vagra...@googlegroups.com
Jamie,
Understood. However, you can quite easily automate the install of Vagrant on any platform. I use the native platform packages for each (MSI for Windows, PKG for Mac, etc.), and each of these formats has been specifically designed to allow for hands-free installation.
In that case, you simply have to modify the script to use the command-line installation of the package format you're interested in. Voila!
Mitchell
On Tue, Apr 30, 2013 at 3:24 AM, Jamie Kirkpatrick <j...@spotify.com> wrote:
I'm very late to the party I know but I'd like to express some disappointment at going down an installer-only route. I understand your reasoning, strong isolation is a good thing, and like you said, some dependencies aren't easily managed with Gems.That said, the automated use-case might be more widespread than you think. I for one have built a whole automated developer box building workflow using Vagrant and Veewee and using bundler/rvm to isolate things has worked perfectly for us so far. Now I'm going to have a very hard time automating the whole thing which kind of defeats the point - currently I have a single script developers can run to provision all kinds of environments totally automatically.I know you will probably say that they already have to install VirtualBox manually and this is true, but as I add more and more things to the list of manual steps the value diminishes. I'd really love it if you would at least consider maintaining a gemspec so people can install from git/github using bundler if they know how and want that power.
On Thursday, June 14, 2012 12:31:46 AM UTC-4, Mitchell Hashimoto wrote:
--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Mike
Apr 30, 2013, 12:50:32 PM4/30/13
to vagra...@googlegroups.com
In fact, there's already a Chef cookbook to install vagrant on your
platform of choice:
http://community.opscode.com/cookbooks/vagrant
platform of choice:
http://community.opscode.com/cookbooks/vagrant
Mitchell Hashimoto
May 1, 2013, 1:04:34 PM5/1/13
to vagra...@googlegroups.com
Aybars,
I'd love to support more platforms. For now, there isn't support for FreeBSD officially. I may make a documentation page on getting Vagrant to work on other platforms...
Best,
Mitchell
On Wed, May 1, 2013 at 4:52 AM, Aybars Badur <aybars...@gmail.com> wrote:
Hi,For freebsd 9-1. Is there a plan to make binary packages for freebsd ? couldn't find how to build vagrant on freebsd too - googling doesnt help much - is there a document/tutorial, so maybe I can try building and packaging.in other words how can i install vagrant on freebsd ?
--
Julien BALLET
Oct 16, 2013, 2:03:41 PM10/16/13
to vagra...@googlegroups.com
Hi,
Thank you for the good job with vagrant.
--Julien.
Teemu Matilainen
Oct 17, 2013, 9:19:45 AM10/17/13
to vagra...@googlegroups.com
Hi Julien,
Mitchell explains his decisions in this blog post: http://mitchellh.com/abandoning-rubygems
Then there is https://github.com/org-binbab/gem-vagrant-wrapper but I have no experience with it.
--
Cheers,
- Teemu
--
Reply all
Reply to author
Forward
0 new messages