Enable Windows users with SSH installed to use 'vagrant ssh' #933

Closed
wants to merge 4 commits into
from

Conversation

Projects
None yet
@webcoyote
Contributor

webcoyote commented May 17, 2012

Hello Mitchell,

I think vagrant is awesome, thank you.

I use vagrant on Windows and discovered that 'vagrant ssh' just leads to an error message that says 'use putty'. But I already have ssh on my system because it is included with git (and cygwin, and mingw). So I changed the vagrant code so that it works more like the *nix version and uses "which" to discover whether ssh is already installed. This required that I write a platform independent "which" function in Ruby and some unit tests. And I tested it on Windows and Linux (Ubuntu Lucid).

I hope you like it; please let me know if there's anything you'd like me to change and I will gladly do so.

Best,

Pat

Patrick Wyatt - "webcoyote"

@cal

This comment has been minimized.

Show comment
Hide comment
@cal

cal May 17, 2012

What about supporting direct launching of PuTTY?

cal commented May 17, 2012

What about supporting direct launching of PuTTY?

@webcoyote

This comment has been minimized.

Show comment
Hide comment
@webcoyote

webcoyote May 18, 2012

Contributor

Hello Cal,

While I've used Putty before (a long time ago), I much prefer console-based SSH clients like the ones in Cygwin, MinGW and Git because the ssh session stays in the same console window, and all the proper command-line arguments are supported. I updated my pull request to include another commit that restores the old "try Putty with these arguments" error message (which only shows when no SSH is found, and only on Windows).

I will look into what's necessary to launch Putty on Windows in the event that an SSH client is not found, but I probably can't do it for several days. I would prefer to do that change as part of a separate pull request, if that's okay with you.

Incidentally, I tried to squash my two commits together but apparently my git-fu isn't strong enough; I'm not sure if I'm doing something wrong, or if it just isn't possible since I already pushed my first commit to GitHub.

In any event, hope you like the latest version!

Best,

Pat

Contributor

webcoyote commented May 18, 2012

Hello Cal,

While I've used Putty before (a long time ago), I much prefer console-based SSH clients like the ones in Cygwin, MinGW and Git because the ssh session stays in the same console window, and all the proper command-line arguments are supported. I updated my pull request to include another commit that restores the old "try Putty with these arguments" error message (which only shows when no SSH is found, and only on Windows).

I will look into what's necessary to launch Putty on Windows in the event that an SSH client is not found, but I probably can't do it for several days. I would prefer to do that change as part of a separate pull request, if that's okay with you.

Incidentally, I tried to squash my two commits together but apparently my git-fu isn't strong enough; I'm not sure if I'm doing something wrong, or if it just isn't possible since I already pushed my first commit to GitHub.

In any event, hope you like the latest version!

Best,

Pat

@webcoyote

This comment has been minimized.

Show comment
Hide comment
@webcoyote

webcoyote May 21, 2012

Contributor

I looked into adding Putty support in ssh.rb but it turns out there are problems:

  1. OpenSSH SSH-2 keys created by vagrant aren't capable of being loaded directly by Putty; it's necessary to convert them to Putty format keys. Unfortunately this cannot be automated because PuttyGen doesn't support command-line conversion. So users would need to perform manual steps to make Putty work.
  2. Putty supports only a subset of the ssh options that are used by the lib/vagrant/ssh.rb script. While Putty can probably be made to work by writing code to strip the unknown options, it would be fragile. As new ssh options are added to the vagrant command-line, it would probably break support for Putty, or even potentially lead to security holes if the option were critical.

Personally I prefer using ssh.exe, which allows launching the ssh window in the same console. When using Putty, it launches a separate windows application, which makes it more-or-less impossible to pipe input/output to "vagrant ssh" for scripting purposes.

I would suggest that folks who want to use "vagrant ssh" should just install something that uses ssh. Inasmuch as ssh comes with git on Windows, it's pretty straightforward.

Contributor

webcoyote commented May 21, 2012

I looked into adding Putty support in ssh.rb but it turns out there are problems:

  1. OpenSSH SSH-2 keys created by vagrant aren't capable of being loaded directly by Putty; it's necessary to convert them to Putty format keys. Unfortunately this cannot be automated because PuttyGen doesn't support command-line conversion. So users would need to perform manual steps to make Putty work.
  2. Putty supports only a subset of the ssh options that are used by the lib/vagrant/ssh.rb script. While Putty can probably be made to work by writing code to strip the unknown options, it would be fragile. As new ssh options are added to the vagrant command-line, it would probably break support for Putty, or even potentially lead to security holes if the option were critical.

Personally I prefer using ssh.exe, which allows launching the ssh window in the same console. When using Putty, it launches a separate windows application, which makes it more-or-less impossible to pipe input/output to "vagrant ssh" for scripting purposes.

I would suggest that folks who want to use "vagrant ssh" should just install something that uses ssh. Inasmuch as ssh comes with git on Windows, it's pretty straightforward.

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh May 23, 2012

Member

This looks pretty good, and it will definitely make using Vagrant for Windows users easier if they have ssh installed (which many will I'd imagine if they uses msysgit). Cool stuff. I'll take a look into merging this soon.

Member

mitchellh commented May 23, 2012

This looks pretty good, and it will definitely make using Vagrant for Windows users easier if they have ssh installed (which many will I'd imagine if they uses msysgit). Cool stuff. I'll take a look into merging this soon.

@wilmoore

This comment has been minimized.

Show comment
Hide comment
@wilmoore

wilmoore Jun 4, 2012

As an aside, I've relied on the GNU Win32 utilities for years. They are my goto when Windows use is a necessity.
Here is a link to the which command: http://gnuwin32.sourceforge.net/packages/which.htm; however, pretty much any utility you'd need is available as well: http://gnuwin32.sourceforge.net/packages.html.

I'm not sure if you can bundle the binaries or not (RE: licensing), but at the very least, prompting a user to put one or more of these binaries in their path may not be a terrible solution. Perhaps even make them a requirement for use on windows.

Alternatively, I'm sure there are by now many powershell-based equivalents. For example:

Get-command -commandtype application

wilmoore commented Jun 4, 2012

As an aside, I've relied on the GNU Win32 utilities for years. They are my goto when Windows use is a necessity.
Here is a link to the which command: http://gnuwin32.sourceforge.net/packages/which.htm; however, pretty much any utility you'd need is available as well: http://gnuwin32.sourceforge.net/packages.html.

I'm not sure if you can bundle the binaries or not (RE: licensing), but at the very least, prompting a user to put one or more of these binaries in their path may not be a terrible solution. Perhaps even make them a requirement for use on windows.

Alternatively, I'm sure there are by now many powershell-based equivalents. For example:

Get-command -commandtype application
@webcoyote

This comment has been minimized.

Show comment
Hide comment
@webcoyote

webcoyote Jun 4, 2012

Contributor

Wilmoore, thanks for the comments. I wrote a pure-ruby solution to implement "which" to avoid adding any additional dependencies on Vagrant. Since it isn't my project I didn't want to force the maintainers into using those dependencies.

I did make a minor modification to the error message that pops up on Windows to make it more clear that an SSH client needs to be installed.

Contributor

webcoyote commented Jun 4, 2012

Wilmoore, thanks for the comments. I wrote a pure-ruby solution to implement "which" to avoid adding any additional dependencies on Vagrant. Since it isn't my project I didn't want to force the maintainers into using those dependencies.

I did make a minor modification to the error message that pops up on Windows to make it more clear that an SSH client needs to be installed.

+ # http://stackoverflow.com/questions/2108727/which-in-ruby-checking-if-program-exists-in-path-from-ruby
+ def self.which(cmd)
+
+ # If the PATHEXT variable is empty, we're on *nix and need to find the exact filename

This comment has been minimized.

@wilmoore

wilmoore Jun 4, 2012

@webcoyote

Would the following perhaps be safer?:

Config::CONFIG['host_os'].include? 'mswin'

It may prove to be safer to go with a system flag such as this over a mutable environment variable.

@wilmoore

wilmoore Jun 4, 2012

@webcoyote

Would the following perhaps be safer?:

Config::CONFIG['host_os'].include? 'mswin'

It may prove to be safer to go with a system flag such as this over a mutable environment variable.

This comment has been minimized.

@webcoyote

webcoyote Jun 4, 2012

Contributor

You're right that using the PATHEXT variable as a way to detect Windows is
lame, but Config (deprecated) and RbConfig also seems to be fairly broken:

RbConfig::CONFIG['host_os'] =~ /mswin|windows|cygwin/i ==> nil (bogus!)

RbConfig::CONFIG['host_os'] =~ /mswin|windows|cygwin|mingw/i ==> 0 (found)

RUBY_PLATFORM ==> "i386-mingw32"

sigh.

However, it turns out that there is a "windows?" function in Util, part of
the vagrant project, so I'll use that.

Pat

On Mon, Jun 4, 2012 at 12:43 PM, Wil Moore III <
reply@reply.github.com

wrote:

@@ -0,0 +1,36 @@
+module Vagrant

@webcoyote

Would the following perhaps be safer?:

Config::CONFIG['host_os'].include? 'mswin'

It may prove to be safer to go with a system flag such as this over a
mutable environment variable.


Reply to this email directly or view it on GitHub:
https://github.com/mitchellh/vagrant/pull/933/files#r924609

@webcoyote

webcoyote Jun 4, 2012

Contributor

You're right that using the PATHEXT variable as a way to detect Windows is
lame, but Config (deprecated) and RbConfig also seems to be fairly broken:

RbConfig::CONFIG['host_os'] =~ /mswin|windows|cygwin/i ==> nil (bogus!)

RbConfig::CONFIG['host_os'] =~ /mswin|windows|cygwin|mingw/i ==> 0 (found)

RUBY_PLATFORM ==> "i386-mingw32"

sigh.

However, it turns out that there is a "windows?" function in Util, part of
the vagrant project, so I'll use that.

Pat

On Mon, Jun 4, 2012 at 12:43 PM, Wil Moore III <
reply@reply.github.com

wrote:

@@ -0,0 +1,36 @@
+module Vagrant

@webcoyote

Would the following perhaps be safer?:

Config::CONFIG['host_os'].include? 'mswin'

It may prove to be safer to go with a system flag such as this over a
mutable environment variable.


Reply to this email directly or view it on GitHub:
https://github.com/mitchellh/vagrant/pull/933/files#r924609

This comment has been minimized.

@wilmoore

wilmoore Jun 4, 2012

@webcoyote Yeah, that's a bummer about RbConfig and RUBY_PLATFORM...but good call on the Util stuff :)

@wilmoore

wilmoore Jun 4, 2012

@webcoyote Yeah, that's a bummer about RbConfig and RUBY_PLATFORM...but good call on the Util stuff :)

@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Jun 15, 2012

Isn't there a where.exe on all Windowses (ignoring XP)?

Related to https://gist.github.com/2843680

haf commented Jun 15, 2012

Isn't there a where.exe on all Windowses (ignoring XP)?

Related to https://gist.github.com/2843680

@webcoyote

This comment has been minimized.

Show comment
Hide comment
@webcoyote

webcoyote Jun 20, 2012

Contributor

Haf - you're right; Windows (non-XP) users could use the 'where' command; I wasn't aware this was added in Server 2003 and beyond. I'm happy to write the code to use "where" if it exists, but would like some guidance from mitchellh as to what solution he prefers.

Currently implemented in this pull-request: On Windows, use "which" function written in Ruby.
Proposed by Haf: On Windows (> WinXP), use "where" function (if it exists), otherwise fall back to solution above.

The advantage of the current solution is that it's already done. The disadvantage is that "where" is presumably more likely to be correct, thought it is not supported on Windows XP without downloading the utility separately. My suggestion would be to accept this pull request, then additional changes can be added later if desired.

Whatchya want me to do?

Pat

Contributor

webcoyote commented Jun 20, 2012

Haf - you're right; Windows (non-XP) users could use the 'where' command; I wasn't aware this was added in Server 2003 and beyond. I'm happy to write the code to use "where" if it exists, but would like some guidance from mitchellh as to what solution he prefers.

Currently implemented in this pull-request: On Windows, use "which" function written in Ruby.
Proposed by Haf: On Windows (> WinXP), use "where" function (if it exists), otherwise fall back to solution above.

The advantage of the current solution is that it's already done. The disadvantage is that "where" is presumably more likely to be correct, thought it is not supported on Windows XP without downloading the utility separately. My suggestion would be to accept this pull request, then additional changes can be added later if desired.

Whatchya want me to do?

Pat

@wilmoore

This comment has been minimized.

Show comment
Hide comment
@wilmoore

wilmoore Jun 20, 2012

How the heck did I miss that? It was actually around since 2000 server and seems to be available on XP as well according to this article: http://technet.microsoft.com/en-us/library/cc753148(v=ws.10)

Good call @haf

How the heck did I miss that? It was actually around since 2000 server and seems to be available on XP as well according to this article: http://technet.microsoft.com/en-us/library/cc753148(v=ws.10)

Good call @haf

@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Jun 21, 2012

Glad I could help. Vagrant is awesome btw.

haf commented Jun 21, 2012

Glad I could help. Vagrant is awesome btw.

@taurus-forever

This comment has been minimized.

Show comment
Hide comment
@taurus-forever

taurus-forever Aug 1, 2012

Cherry-picked on v1.0.3 and tested on Win7 x64. It works well, tnx!

Cherry-picked on v1.0.3 and tested on Win7 x64. It works well, tnx!

@webcoyote

This comment has been minimized.

Show comment
Hide comment
@webcoyote

webcoyote Aug 1, 2012

Contributor

Thanks for the kudos; it's always nice to know that something one does is
helpful to others! I think vagrant is awesome, and use it quite a lot, so
I'm glad to contribute back.

On Wed, Aug 1, 2012 at 6:14 AM, taurus-forever <
reply@reply.github.com

wrote:

Cherry-picked on v1.0.3 and tested on Win7 x64. It works well, tnx!


Reply to this email directly or view it on GitHub:
mitchellh#933 (comment)

Contributor

webcoyote commented Aug 1, 2012

Thanks for the kudos; it's always nice to know that something one does is
helpful to others! I think vagrant is awesome, and use it quite a lot, so
I'm glad to contribute back.

On Wed, Aug 1, 2012 at 6:14 AM, taurus-forever <
reply@reply.github.com

wrote:

Cherry-picked on v1.0.3 and tested on Win7 x64. It works well, tnx!


Reply to this email directly or view it on GitHub:
mitchellh#933 (comment)

@jsoriano

This comment has been minimized.

Show comment
Hide comment
@jsoriano

jsoriano Sep 10, 2012

Hey, that's a quite useful piece of code, haven't you tried to request a pull of this branch to the official repo?

Hey, that's a quite useful piece of code, haven't you tried to request a pull of this branch to the official repo?

This comment has been minimized.

Show comment
Hide comment
@webcoyote

webcoyote Jan 14, 2013

Owner

Shoot; just found this message, sorry! I did send a pull request and it never got merged

mitchellh#933

Thanks for the kind words!

Pat

Owner

webcoyote replied Jan 14, 2013

Shoot; just found this message, sorry! I did send a pull request and it never got merged

mitchellh#933

Thanks for the kind words!

Pat

@radim

This comment has been minimized.

Show comment
Hide comment
@radim

radim Oct 4, 2012

Coming back to PuTTY - wouldn't be a good solution to provide insecure key by default as putty formatted key too (if running on Windows) and work from there? Together with bundled PuTTY it would present an easy way how to fix vagrant ssh if no other alternatives are available.

Any PPK key can be generate automatically using putty-tools like this

    puttygen id_rsa -o mykey.ppk

I'm looking at this from perspective of on-boarding new users to use vagrant.

Thanks.

radim commented Oct 4, 2012

Coming back to PuTTY - wouldn't be a good solution to provide insecure key by default as putty formatted key too (if running on Windows) and work from there? Together with bundled PuTTY it would present an easy way how to fix vagrant ssh if no other alternatives are available.

Any PPK key can be generate automatically using putty-tools like this

    puttygen id_rsa -o mykey.ppk

I'm looking at this from perspective of on-boarding new users to use vagrant.

Thanks.

@corydolphin

This comment has been minimized.

Show comment
Hide comment
@corydolphin

corydolphin Dec 23, 2012

Many Windows users who use Vagrant will likely have ssh installed and in their path. I think it would be better to actually try and execute the command before providing an error message, a la "easier to ask for forgiveness than permission."

Many Windows users who use Vagrant will likely have ssh installed and in their path. I think it would be better to actually try and execute the command before providing an error message, a la "easier to ask for forgiveness than permission."

@haf

This comment has been minimized.

Show comment
Hide comment
@haf

haf Dec 23, 2012

@wcdolphin I agree completely.

haf commented Dec 23, 2012

@wcdolphin I agree completely.

@webcoyote

This comment has been minimized.

Show comment
Hide comment
@webcoyote

webcoyote Dec 23, 2012

Contributor

wcdolphin said: "Many Windows users who use Vagrant will likely have ssh installed and in their path. I think it would be better to actually try and execute the command before providing an error message..."

As the author of this pull request, I agree too!

I prefer ssh to Putty on Windows, but to be friendly I wrote my patch to keep the behavior of vagrant-ssh unchanged for Putty users. Apparently this pull request does "too much" since it hasn't been merged. However, it now appears that putty support has been dropped in lib/vagrant/util/ssh.rb anyway.

All that's necessary is to drop the "if Platform.windows?" and "raise Errors::SSHUnavailable if !Kernel.system("which ssh") and ssh works fine on Windows (assuming that ssh exists...).

Contributor

webcoyote commented Dec 23, 2012

wcdolphin said: "Many Windows users who use Vagrant will likely have ssh installed and in their path. I think it would be better to actually try and execute the command before providing an error message..."

As the author of this pull request, I agree too!

I prefer ssh to Putty on Windows, but to be friendly I wrote my patch to keep the behavior of vagrant-ssh unchanged for Putty users. Apparently this pull request does "too much" since it hasn't been merged. However, it now appears that putty support has been dropped in lib/vagrant/util/ssh.rb anyway.

All that's necessary is to drop the "if Platform.windows?" and "raise Errors::SSHUnavailable if !Kernel.system("which ssh") and ssh works fine on Windows (assuming that ssh exists...).

@michfield

This comment has been minimized.

Show comment
Hide comment
@michfield

michfield Jan 8, 2013

I really do think this must be merged.
I even have automated script for patching Vagrant :(

...

And I really think it's stupid to do this anymore. It's been almost a year...

...

Find the location of a file

    for /f "tokens=*" %f in ('where /R "c:\vagrant" "ssh.rb" ^| grep "embedded\\\lib\\\ruby\\\gems\\\.*\\\gems\\\vagrant.*\\\lib\\\vagrant\\\ssh.rb"') do @(set _TMP=%f)

And patch that `ssh.rb` file

    (
    echo/57a58
    echo/^> =begin
    echo/65a67,71
    (echo/^> )
    echo/^> =end
    (echo/^> )
    echo/^>       which = Util::Platform.windows? ? "where ssh >NUL 2>&1" : "which ssh >/dev/null 2>&1"
    echo/^>       raise Errors::SSHUnavailable if !Kernel.system^(which^)
    ) >vagrant-ssh-windows-patch.diff

    patch -i vagrant-ssh-windows-patch.diff "%_TMP%"

And remove residues.

    del vagrant-ssh-windows-patch.diff

SSH in Vagrant will now work as supposed to:

    vagrant ssh

I really do think this must be merged.
I even have automated script for patching Vagrant :(

...

And I really think it's stupid to do this anymore. It's been almost a year...

...

Find the location of a file

    for /f "tokens=*" %f in ('where /R "c:\vagrant" "ssh.rb" ^| grep "embedded\\\lib\\\ruby\\\gems\\\.*\\\gems\\\vagrant.*\\\lib\\\vagrant\\\ssh.rb"') do @(set _TMP=%f)

And patch that `ssh.rb` file

    (
    echo/57a58
    echo/^> =begin
    echo/65a67,71
    (echo/^> )
    echo/^> =end
    (echo/^> )
    echo/^>       which = Util::Platform.windows? ? "where ssh >NUL 2>&1" : "which ssh >/dev/null 2>&1"
    echo/^>       raise Errors::SSHUnavailable if !Kernel.system^(which^)
    ) >vagrant-ssh-windows-patch.diff

    patch -i vagrant-ssh-windows-patch.diff "%_TMP%"

And remove residues.

    del vagrant-ssh-windows-patch.diff

SSH in Vagrant will now work as supposed to:

    vagrant ssh

@LeeSaferite

This comment has been minimized.

Show comment
Hide comment
@LeeSaferite

LeeSaferite Jan 21, 2013

Why on earth has this NOT been merged or at least a similar function implemented?

I love vagrant but unfortunately I cannot always work from a mac or linux machine. Having to manually setup my dev box to properly connect is annoying to say the least. And having to manually patch the vagrant files on each install does not scale for the rest of my team.

Seiriously though @mitchellh , what's the point of saying "I'll take a look into merging this soon" and 8 months later the current version still has not fixed this bug?

Why on earth has this NOT been merged or at least a similar function implemented?

I love vagrant but unfortunately I cannot always work from a mac or linux machine. Having to manually setup my dev box to properly connect is annoying to say the least. And having to manually patch the vagrant files on each install does not scale for the rest of my team.

Seiriously though @mitchellh , what's the point of saying "I'll take a look into merging this soon" and 8 months later the current version still has not fixed this bug?

@corydolphin

This comment has been minimized.

Show comment
Hide comment
@corydolphin

corydolphin Jan 21, 2013

If there is any way we can help to get this patch in, please let us know, we Windows users obviously feel strongly about it.
There are a number of pull requests with very similar diffs, implementing and fixing the issue. I count four active currently.
mitchellh#1309
mitchellh#1156
mitchellh#1083

If there is any way we can help to get this patch in, please let us know, we Windows users obviously feel strongly about it.
There are a number of pull requests with very similar diffs, implementing and fixing the issue. I count four active currently.
mitchellh#1309
mitchellh#1156
mitchellh#1083

@webcoyote

This comment has been minimized.

Show comment
Hide comment
@webcoyote

webcoyote Jan 21, 2013

Contributor

@LeeSaferite - As someone who uses SSH on Windows I understand your frustration, but not your method of dealing with the problem. This is an easy problem to solve -- just fork the vagrant repository, incorporate my change (or one of the others mentioned by @wcdolphin), and install that version of vagrant instead of the default. Presumably you're using Chef or Puppet for system setup so it should be easy.

We should be thankful that @mitchellh has done such excellent work creating vagrant in the first place!

Contributor

webcoyote commented Jan 21, 2013

@LeeSaferite - As someone who uses SSH on Windows I understand your frustration, but not your method of dealing with the problem. This is an easy problem to solve -- just fork the vagrant repository, incorporate my change (or one of the others mentioned by @wcdolphin), and install that version of vagrant instead of the default. Presumably you're using Chef or Puppet for system setup so it should be easy.

We should be thankful that @mitchellh has done such excellent work creating vagrant in the first place!

@LeeSaferite

This comment has been minimized.

Show comment
Hide comment
@LeeSaferite

LeeSaferite Jan 21, 2013

@webcoyote Forking and then building an installer is of course a solution to the problem. I just don't want to maintain a forked version for the fix when the fix is so simple and should be in the trunk. The fact that @mitchellh indicated he would get this merged in so long ago and it has yet to happen is what I find so frustrating.

@mitchellh No disrespect is intended. Vagrant is a wonderful tool and I use it every day. It made life as a freelancer SO much simpler. I used to manually maintain VMs for each project and that was a nightmare.

@webcoyote Forking and then building an installer is of course a solution to the problem. I just don't want to maintain a forked version for the fix when the fix is so simple and should be in the trunk. The fact that @mitchellh indicated he would get this merged in so long ago and it has yet to happen is what I find so frustrating.

@mitchellh No disrespect is intended. Vagrant is a wonderful tool and I use it every day. It made life as a freelancer SO much simpler. I used to manually maintain VMs for each project and that was a nightmare.

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Jan 21, 2013

Member

@LeeSaferite I apologize for keeping this issue for so long. It was definitely not my intention but let me explain what has been going on, and when/how this will get merged at some point.

As you probably know, Vagrant 1.0.x is the released version of Vagrant. This is a stable release, meaning I'm only adding bug fixes, and not introducing any new features. Because many thousands of individuals and companies rely on this version, I will not backport this there.

That means that this will get merged into a newer release, which would be 1.1. This version hasn't been released, and has been in development for nearly 10 months. Oof! Why? Well, first of all, I didn't start working full time on Vagrant until just under 2 months ago. Prior to that, Vagrant was a side project I worked on after getting home from my full time job, so I'd only be able to dedicate 2 to 4 hours a night on it (unfortunately, hence me quitting my job!).

More importantly though, Vagrant 1.1 introduces foundational shifts in the core of Vagrant. Primarily, this is the shift away from VirtualBox to a backend-agnostic model, all while keeping backwards compatibility and attempting to keep stability (despite 1.x being an unstable series up towards 2.0). This has been a monumentally large task touching every part of Vagrant: lifecycle management, networking, shared folders, configuration, etc. Again, while keeping backwards compatibility.

Determining how I would make even bits and pieces of this work have taken months: Conceptualizing the "provider" abstraction took 3 months of planning, the "network" abstraction wasn't realized until a month ago, etc.

The GREAT news is that 1.1 is pretty much there. VirtualBox is not tied to the core anymore, I have a working VMWare Fusion provider I'll announce soon, and I have a few companies actually using git master in production (brave, I don't recommend it, but it is working!).

Okay, who cares? What does this have to do with Windows? Sorry it took so long to get to the point:

While working on these foundational core shifts, I've chosen to basically ignore any pull requests or non-critical issues until after I've really laid the building blocks down for the next generation of Vagrant. I hope this makes sense, but if not: Any more code I add to the "old" codebase is just more to potentially refactor into the "new" codebase (I put old and new in quotes because nothing was rewritten, but major changes have been made).

Unfortunately, this issue came early on in the 1.1 lifecycle.

I plan on releasing 1.1 very soon, and then spend a huge effort making enhancements all across the board to Vagrant by merging in pull requests such as these and attending minor issues.

I'm sorry if this has been a frustrating experience for the people here. Windows is a huge part of Vagrant and I have/had no intention of ignoring you all here. Windows will get ssh very soon (post-1.1), and the release cycle of 1.x will increase SHARPLY after 1.1, since the major time sink has been conceptualizing core abstractions, which is coming to a close.

Feel free to ask any questions, I'm happy to answer.

Member

mitchellh commented Jan 21, 2013

@LeeSaferite I apologize for keeping this issue for so long. It was definitely not my intention but let me explain what has been going on, and when/how this will get merged at some point.

As you probably know, Vagrant 1.0.x is the released version of Vagrant. This is a stable release, meaning I'm only adding bug fixes, and not introducing any new features. Because many thousands of individuals and companies rely on this version, I will not backport this there.

That means that this will get merged into a newer release, which would be 1.1. This version hasn't been released, and has been in development for nearly 10 months. Oof! Why? Well, first of all, I didn't start working full time on Vagrant until just under 2 months ago. Prior to that, Vagrant was a side project I worked on after getting home from my full time job, so I'd only be able to dedicate 2 to 4 hours a night on it (unfortunately, hence me quitting my job!).

More importantly though, Vagrant 1.1 introduces foundational shifts in the core of Vagrant. Primarily, this is the shift away from VirtualBox to a backend-agnostic model, all while keeping backwards compatibility and attempting to keep stability (despite 1.x being an unstable series up towards 2.0). This has been a monumentally large task touching every part of Vagrant: lifecycle management, networking, shared folders, configuration, etc. Again, while keeping backwards compatibility.

Determining how I would make even bits and pieces of this work have taken months: Conceptualizing the "provider" abstraction took 3 months of planning, the "network" abstraction wasn't realized until a month ago, etc.

The GREAT news is that 1.1 is pretty much there. VirtualBox is not tied to the core anymore, I have a working VMWare Fusion provider I'll announce soon, and I have a few companies actually using git master in production (brave, I don't recommend it, but it is working!).

Okay, who cares? What does this have to do with Windows? Sorry it took so long to get to the point:

While working on these foundational core shifts, I've chosen to basically ignore any pull requests or non-critical issues until after I've really laid the building blocks down for the next generation of Vagrant. I hope this makes sense, but if not: Any more code I add to the "old" codebase is just more to potentially refactor into the "new" codebase (I put old and new in quotes because nothing was rewritten, but major changes have been made).

Unfortunately, this issue came early on in the 1.1 lifecycle.

I plan on releasing 1.1 very soon, and then spend a huge effort making enhancements all across the board to Vagrant by merging in pull requests such as these and attending minor issues.

I'm sorry if this has been a frustrating experience for the people here. Windows is a huge part of Vagrant and I have/had no intention of ignoring you all here. Windows will get ssh very soon (post-1.1), and the release cycle of 1.x will increase SHARPLY after 1.1, since the major time sink has been conceptualizing core abstractions, which is coming to a close.

Feel free to ask any questions, I'm happy to answer.

@wilmoore

This comment has been minimized.

Show comment
Hide comment

👍

@LeeSaferite

This comment has been minimized.

Show comment
Hide comment
@LeeSaferite

LeeSaferite Jan 21, 2013

@mitchellh Fair enough. And I'm looking forward to 1.1 as well because I really don't like VB on mu Linux machines.

Have you considered letting others help maintain 1.0 while you complete 1.1?

@mitchellh Fair enough. And I'm looking forward to 1.1 as well because I really don't like VB on mu Linux machines.

Have you considered letting others help maintain 1.0 while you complete 1.1?

@justinmayer

This comment has been minimized.

Show comment
Hide comment
@justinmayer

justinmayer Jan 21, 2013

Letting others help maintain 1.0 would still likely require Mitchell's time and attention from an oversight perspective, thereby slowing down development of 1.1. Plus, given the following factors:

  1. Mitchell is now working on Vagrant full-time
  2. He's already said Windows will get ssh support soon after 1.1 is released
  3. Using your own fork is always available as an interim measure

... it seems to me the focus should instead be on getting 1.1 out the door.

Just my two cents, of course. 😄

Letting others help maintain 1.0 would still likely require Mitchell's time and attention from an oversight perspective, thereby slowing down development of 1.1. Plus, given the following factors:

  1. Mitchell is now working on Vagrant full-time
  2. He's already said Windows will get ssh support soon after 1.1 is released
  3. Using your own fork is always available as an interim measure

... it seems to me the focus should instead be on getting 1.1 out the door.

Just my two cents, of course. 😄

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Jan 22, 2013

Member

Maintaining 1.0 is really not that difficult. The good thing about the "stable" release is that it is quite stable. 😄 There are missing features and enhancements which would be really nice (like this one), but very few bugs that require backports.

Member

mitchellh commented Jan 22, 2013

Maintaining 1.0 is really not that difficult. The good thing about the "stable" release is that it is quite stable. 😄 There are missing features and enhancements which would be really nice (like this one), but very few bugs that require backports.

@mitchellh

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Feb 9, 2013

Member

Merged: bd06bea

Style nitpicks (for educational value): 38e1600

<3

Member

mitchellh commented Feb 9, 2013

Merged: bd06bea

Style nitpicks (for educational value): 38e1600

<3

@mitchellh mitchellh closed this Feb 9, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment