Closed njam closed 5 years ago
This way we can avoid passing the gems directory along, because vagrant sets all of that up for us.
Interesting idea. I need to look a bit closer at this. There seems to be some issues with the tests on Windows though.
It seems like vagrant
is not on the PATH (is it the right term?) on this Windows build. Do you know what is the best course of action?
Do you know what is the best course of action?
Not out of the top of my head. If it is really just a PATH issue, we can just make sure vagrant is added to the PATH. One would expect though that it is. I guess I would like to know why it is not on the PATH first. Give me a few days to look into this. I am a bit swamped with other things right now, but hopefully I get a bit of time over the next days to look into this.
Anyone mind if I poke this issue to see what its status is? :)
Any news on this? Is this repo maintained anymore?
I am going to close this pull request. I am not generally opposed to this, but as part of issue #324 Landrush already upgraded to Vagrant 2.1.2. AFAICT everything works fine.
I can see that the proposed change makes things a bit easier since we let Vagrant deal with setting up the various paths. At the same time, it relies on vagrant being on the PATH. In most cases that might be the case, but not always (see the AppVeyor).
Regarding the problem which occurred when the gem path changed, the server start script worked as expected. However, due to the change one either needed to delete ~/.vagrant.d or do a reinstall of the plugin.
Addressing #295
Instead of running the DNS server with
ruby start_server.rb 10053 --gem_path=~/.vagrant.d/gems/gems
we could start it as a plugin command:This way we can avoid passing the gems directory along, because vagrant sets all of that up for us.
wdyt?