1. Function composition middleware
Actually, I simply use classes as a way to do function composition. The reason I chose classes over functions I think doesn't really matter in the grand scheme of things, but in my talk I mention that what I am doing is function composition, and I spent a solid 5 to 10 minutes explaining how function composition solves the problem. :) We're on the same page here.
2. The fact you don't have the requirements for the situation I posted.
I understand this, and that is why Vagrant works for you. But it also works for people who do have requirements other than yours. There is a _huge_ amount of Windows users out there that love Vagrant because it now makes Ruby on Rails and so on development work well! If I catered Vagrant to only _my_ requirements (Mac OS X host, Ubuntu guest), then Vagrant would indeed be a lot simpler, but Vagrant as a tool gets a lot of its power and usefulness out of its ability to work in heterogenous environments.
3. `vagrant ssh` is slow. This must be caused by complexity.
This has nothing to do with complexity. This is caused by poorly optimized code paths and how things work up to that point. I just want to note that nowadays `vagrant` commands across the board are a LOT faster. But there is still a lot of work to be done. Specifically the `vagrant ssh` case will get a massive speedup due to cached SSH info.
I specifically have issue with "complexity causes slowness." Sure, it happens, but it doesn't HAVE to, and I'll show that to be true.
4. Plumping and porcelain Git vs Vagrant
Perhaps there is an option here to use unix-type piping to provide an API via plumbing commands. I've decided to take a different approach. Will this work well? Time will tell, but I don't think its fair to criticize Vagrant at this point before this is proven/disproven yet.
5. 12000 lines of Ruby.
~3500 is test code.
~5500 is "plugins" but there is a lot of boilerplate here. The boilerplate is on purpose, I didn't want any "magic," hence it being somewhat Java-like, I suppose, but this is a lot more friendly to non-Ruby developers, and a vast majority of Vagrant users are not Ruby developers. Note that ~3000 of this is ONLY the VirtualBox plugin, which is a pretty complex piece, so that makes sense. The other ~2500 is _every other_ feature of Vagrant.
~3300 is core code. This is mostly a glorified plugin runner that handles plumbing for you, such as hooking up the right host/guest combination, choosing the right communication (SSH, WinRM, etc.) for the machine, error handling, etc.
1. When you first started with Vagrant, did you consider using Python at all? Did you consider using libvirt? Because VirtualBox offers a Python API out of the box (or it does now) and libvirt comes with direct support for Python (http://libvirt.org/bindings.html). I like Ruby and generally I prefer it to Python but I am interested in your view of whether it was the right tool for the job in this case or whether the language choice didn't matter much.
2. In your view what is the overlap in functionality between libvirt and Vagrant and what are the differences? As far as I can see libvirt does let you spin up boxes, talk to them and tear them down. The notable difference is that there is no Puppet of Chef provisioning, is there anything else beyond that?
3. veewee in version 0.3.0 (currently in beta) seems to offer the same functionality as Vagrant plus the ability to create boxes using templates, minus the ability to run provisioners. If they add that say in 0.4.0 then it will be 1:1 in terms of features with Vagrant. Any thoughts on this?
Thank you again for your time and for answering in such detail :-)
1. When I first started Vagrant, I was a full time Ruby developer, so Ruby was really the obvious choice for me. I don't really see language as a barrier for using a tool, my opinion is generally use the best tool for the job. And as a Ruby developer that at the time had 4 years of Ruby experience, that was the best tool for the job since I'd get the most productivity out of it. To date, I don't regret this decision. There are some things Ruby is bad at, some things it is good at, but I think I can overcome the bad with time.
2. I think the difference is that Vagrant is a tool focused on user experience and workflow. i.e. it'd be possibly to build Vagrant on top of libvirt. I think libvirt is technically stronger than Vagrant, but Vagrant provides a better overall experience. The overlap is small, we both have a lot to gain from working with each other.
3. A handful of people keep saying that Vagrant is just a "VM setup + provisioning" tool. Vagrant does quite a lot more. The main example I always use is networking because it is usually the most complex. Vagrant makes networks work across Linux, Mac OS X, and Windows, and sets up the hosts and guests properly. VeeWee doesn't do this and won't do this. VeeWee at its core was built to be a VM image creation tool. VM lifecycle control was bolted on later. VeeWee filled a major gap in the Vagrant ecosystem for a long time.
I'm good friends with the creator of VeeWee and we talked all the way back in Oct, 2011 of merging the functionality. He was all for it. Its almost been a year but this work is finally going to get started.
I don't want to talk too much about it until I really start coding, but I can say that no one in his thread has really seen the true scope of what I'm trying to build here. They will. :)
In particular, I've found the discussion of autoconf to be fascinating. I think what fundamentally bothers me about Vagrant is that it feels like autoconf. By that, I mean it's a system which 1) hides a ton of hard work that users don't need to do to target multiple backends 2) accomplishes that hiding through complexity 3) further hides that complexity through an "easy" interface 4) generally just fucking works most of the time 5) is completely maddening to deal with when it does break 6) ideally shouldn't need to exist.
Anyway, I realize that ideals != reality. I also realize that I've got a learned behavior of reinventing the minimal viable tool from fundamentals to avoid dealing with the complexity of problems that I don't have. And furthermore, I realize that my learned behavior is of limited applicability outside of narrow environments, such as my own startup where I own the full stack and make all the rules.