OSX issue when running 'vagrant up'

[gammons]

Using OSX 10.6.6. So I followed the very easy instructions on the website, and no matter what user I used, running 'vagrant up' would always give me an error about some file that Vagrant uses to store data is a directory.

It turns out that the local JSON data store you guys are trying to use defaults to ~/.vagrant, which you already use as a directory to store other things.

09:26 ~ ()$ vagrant box add base http://files.vagrantup.com/lucid32.box
[vagrant] Creating home directory since it doesn't exist: /Users/gammons/.vagrant
[vagrant] Creating home directory since it doesn't exist: /Users/gammons/.vagrant/tmp
[vagrant] Creating home directory since it doesn't exist: /Users/gammons/.vagrant/boxes
[vagrant] Creating home directory since it doesn't exist: /Users/gammons/.vagrant/logs
[vagrant] Downloading with Vagrant::Downloaders::HTTP...
[vagrant] Downloading box: http://files.vagrantup.com/lucid32.box
[vagrant] Extracting box...
[vagrant] Verifying box...
[vagrant] Cleaning up downloaded box...
09:31 ~ ()$ vagrant up
The local file Vagrant uses to store data ".vagrant" already exists
and is a directory! If you are in your home directory, then please run
this command in another directory. If you aren't in a home directory,
then please rename ".vagrant" to something else, or configure Vagrant
to use another filename by modifying config.vagrant.dotfile_name.

I added a very simple patch that emulates how you guys initialize your global store. Now vagrant works perfectly!

[mitchellh]

Grant,

Thanks for this. This is a known issue and is the reason that the error message exists. The reason I can't simply apply your patch is that releasing Vagrant with that patch would immediately break backwards compatibility with everyone which currently has an active Vagrant project, since Vagrant would no longer find the ".vagrant" file.

Instead, what I'd like to do is the opposite of what you've proposed, and transition the "/.vagrant" directory to "/.vagrant.d" which is the more standard unixy filename for that sort of thing.

In order to do this, I'll need to make sure that old users continue to work with ~/.vagrant, and create an automated migration process.

Best,
Mitchell

[gammons]

Mi Mitchell,

Thanks for your reply. I understand the need to keep the status quo for existing users of older versions of vagrant. A migration path does make sense in this case.

However, I do believe there is some urgency around this fix, because all users of the newest version of the vagrant gem will not be able to get up and running at all. The current vagrant gem, as it stands for brand new users, is completely broken.

-Grant

[DavidYKay]

Grant,

Thanks for the fix.

Seconded on the "urgency" as my vagrant install would not work out of the box until applying this patch.

-David

[mikeforbes]

Any update on this fix?

It seems to be pretty broken for anyone on OSX

[davidglassborow]

Agreed, I just following the instructions on the website and immediately failed.
I've patched my gem with the fix above, but it would probably help to at least have a link to this issue on the getting started page for OS X users.

[buzypi]

I tried installing Vagrant via gem install on Ubuntu 10.04 yesterday (May 11th) and ran into this issue.

The fix suggested by @gammons worked.

[mitchellh]

Sorry to everyone who is on this list. I intend to fix this,, and I like @gammons latest update, but it still won't do for a merge since I need to provide a transitionary step for older environments which still use the dotfile_path. :) For now, feel free to use the patch manually, although I recommend creating a Vagrant environment in another folder.

[gammons]

@mitchellh This has been broken for months. Your gem has been completely broken for months. What clients are you catering to, exactly? You're not gaining any new users of this gem. I'm a bit angry because your idea is great, the platform looks great, the vagrant website is very nice. I completely buy into the idea of a chef-driven standardized development VM.

Potential users will come to the vagrant site, see how awesome it is, then try the instructions, and it will fail, and they will curse your name. please apply my patch. I don't want to see the project die.

[mitchellh]

@gammons I have voiced in this pull request why I can't merge this yet, but I have kept it open knowing that this is a valid issue. However, it does not in any way make Vagrant "broken." I work with companies daily, companies that you use daily, that use Vagrant for development, and it works fine (of course its not perfect and I have many plans to improve, but it does work). The "broken" case you're describing is a very contrived case where a user attempts to create a vagrant environment in their $HOME directory. And its "broken" but also gives a very sane message, even telling the user exactly how to work around it. Besides the quick intro, what use case is there in having a Vagrant environment in your home directory?

Now, the reason that I can't merge your patch -- which I am very grateful for -- is because it would break backwards compatibility. If I were to merge your patch, it would break MORE installations than it would fix, since all pre-existing Vagrant environments would fail to find their VM since their local data filename has changed and there is no transitionary step with the current pull request. There needs to be a way for pre-existing Vagrant environments to seamlessly transition to this new setup.

I plan to do this, but this is simply not a high priority bug. There is an error message in place currently which documents how to work around the issue and why it exists, and for any serious use of Vagrant, having the environment in your home directory won't work anyways, since the Vagrant environment should be specific for each project (unless youre entire home directory is your "project!")

I agree that potential users do come to the site and get bit by this, often too! But most quickly realize (by reading the error) what is going on and place the Vagrant environment in their project directories. Such a trivial bug will not cause this project to "die," I assure you, and Vagrant growth has never been so strong.

I will eventually fix this bug, or maybe someone will come and figure out a way to do it before I get to it. Your patch is 100% on the right track, its just not completely there yet. But I do appreciate you taking your time to write the patch and I have been on your end of the pull request where my changes weren't being merged either, so I can understand your frustration, but I don't want this issue to be blown out of proportion or to have any misconceptions about the clarity as to why I'm not merging this pull request.

[DavidYKay]

@mitchellh I may be misunderstanding the issue, but when I attempted to use
Vagrant on Mac OS X before applying this patch, I was unable to use Vagrant
in any directory within $HOME. That is "vagrant init" within
~/path/to/my/project would still break.

If it interests you, I can remove the patch and see if I can reproduce the
bug.

Thanks!

On Thu, May 19, 2011 at 5:14 PM, mitchellh <
reply@reply.github.com>wrote:

@gammons I have voiced in this pull request why I can't merge this yet, but
I have kept it open knowing that this is a valid issue. However, it does not
in any way make Vagrant "broken." I work with companies daily, companies
that you use daily, that use Vagrant for development, and it works fine (of
course its not perfect and I have many plans to improve, but it does work).
The "broken" case you're describing is a very contrived case where a user
attempts to create a vagrant environment in their $HOME directory. And its
"broken" but also gives a very sane message, even telling the user exactly
how to work around it. Besides the quick intro, what use case is there in
having a Vagrant environment in your home directory?

Now, the reason that I can't merge your patch -- which I am very grateful
for -- is because it would break backwards compatibility. If I were to merge
your patch, it would break MORE installations than it would fix, since all
pre-existing Vagrant environments would fail to find their VM since their
local data filename has changed and there is no transitionary step with the
current pull request. There needs to be a way for pre-existing Vagrant
environments to seamlessly transition to this new setup.

I plan to do this, but this is simply not a high priority bug. There is an
error message in place currently which documents how to work around the
issue and why it exists, and for any serious use of Vagrant, having the
environment in your home directory won't work anyways, since the Vagrant
environment should be specific for each project (unless youre entire home
directory is your "project!")

I agree that potential users do come to the site and get bit by this, often
too! But most quickly realize (by reading the error) what is going on and
place the Vagrant environment in their project directories. Such a trivial
bug will not cause this project to "die," I assure you, and Vagrant growth
has never been so strong.

I will eventually fix this bug, or maybe someone will come and figure out a
way to do it before I get to it. Your patch is 100% on the right track, its
just not completely there yet. But I do appreciate you taking your time to
write the patch and I have been on your end of the pull request where my
changes weren't being merged either, so I can understand your frustration,
but I don't want this issue to be blown out of proportion or to have any
misconceptions about the clarity as to why I'm not merging this pull
request.

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

David Young-Chan Kay
http://gravatar.com/DavidYKay
DavidYKay@gmail.com

[mitchellh]

@DavidYKay Now that would be a serious case that I haven't seen before. Do you have steps to reproduce this? That would be something I'd want to fix ASAP. I'll play around with the issue as well and see if I can repro it.

Thanks for bringing this up :)

[davidglassborow]

I have to agree with DavidYKay, I couldn't get vagrant to work at all on OS X until I applied the patch

[gammons]

Couldn't you just do this and call it a day?

    # Loads (on initial access) and reads data from the local data
    # store. This file is always at the root path as the file "~/.vagrant"
    # and contains a JSON dump of a hash. See {DataStore} for more
    # information.
    #
    # @return [DataStore]
    def local_data
      return parent.local_data if parent
      if File.exists?(dotfile_path) && File.directory?(dotfile_path)
        # new user, do not use .vagrant directory as local data store file
        @local_data ||= DataStore.new(File.expand_path("local_data.json", home_path))
      else
        # legacy user, so continue using the dotfile_path as a file.
        @local_data ||= DataStore.new(dotfile_path)
      end
    end

[mitchellh]

@gammons

Yes, this is definitely what is needed here. I'll look into getting this into Vagrant for the next version.

[mitchellh]

This is fixed and pushed. It will be part of version 0.8.0.

I ended up making the migration by moving the home folder rather than renaming the local data folder. This was easier to retain backwards compatibility with and has a nice warning if both the old and new folder exist and a migration can't be made.

[mroderick]

While waiting for 0.8.0 to clear up the confusion, there is a simple way of avoiding this issue.

When following the instructions from http://vagrantup.com/, DO NOT USE YOUR HOMEDIR.

I used ~/code/ and everything work fine.