Hacker News Reader

Comment by dugmartin | Hacker News Reader

Your don't need to give up your GUI editor to do this. Vagrant sets up a shared folder automatically in the virtual environment under /vagrant that maps to the folder where your Vagrantfile is located on the host machine.

I do all my development now using Vagrant running Ubuntu VMs but I still do all my editing with the same Windows editor I've used for years running on the host machine.

View on HN

Or, you know, ssh -X. Oh, but wait, they're trying to get rid of that in Wayland, "because nobody uses it" . . .

I suppose there's always RDP or VNC, if you can stomach their limitations.

That has never been accurate. Wayland has planned X support for a long time, it just won't be in the core

There are at least two other ways to develop with a GUI.

One is the tried and true Xwindow forwarding. Usually conveniently handled by ssh now, but in the olden days (I'm talking early/mid 90s) we used alternatives.

The other is VNC in. This has been extensively discussed by the "I use my ipad as my development machine" crowd. I've had pretty good results with VNC over the ... decades.

This is fine for some scenarios but I've had a series of problems which drove me away from this kind of setup.

Default CarrierWave (Rails gem) settings try to clean up the tmp files after file uploads. This is a good thing normally, but to Ruby I am on a Linix box, so it tries to `unlink` which fails catastrophically because the mounted drive was NTFS.

Then there are NPM modules. It is kind of funny because Node.js and NPM are actually pretty good on Windows for development purposes anyway, but if I want to run it from my VM it picks up my OS as Linix and tries file system operations like symlinks. I couldn't even install Express.

These are just a few of the things I ran into.

The symlinks problem can be mostly resolved by adding this magic incantation to your Vagrantfile:

      # to allow symlinks to be created
  config.vm.customize ["setextradata", :id, "VBoxInternal2/SharedFoldersEnableSymlinksCreate/vagrant", "1"]

That said I have had times where npm via a putty window refuses to install modules. However, I also have npm installed on my Windows box so I can just drop down into a cmd window when that happens and run the npm command there.

You can use Samba shares (win<->nix) or NFS (nix<->*nix) if you don't have Vagrant, or whatever it is :)

That being said - don't! As others said, X protocol is network transparent, let's you display windows on a server from everywhere. That means you can open a GUI tool on VM and see it's window(s) on your desktop, with your window manager decorations and basically indistinguishable from an app on your main system. It's possible on Windows thanks to xming (http://sourceforge.net/projects/xming/) which is a lightweight X server for Windows.

This works nicely when you mainly just using a text editor to edit files in a scripting language and doing any automation stuff from terminal.

If you find yourself using a big IDE it can sometimes be a pain. Most IDEs will let you do remote debugging etc but will still build on the local machine and do use the local JVM to enable some features.

It's worth noting that Jetbrains IDEs seem to be getting support for remote debugging in VMs, and specifically Vagrant support. It's already in PyCharm[1], and hopefully it'll be available in their other IDEs soonish.

[1]: http://blog.jetbrains.com/pycharm/2013/03/how-pycharm-helps-...

PyCharm user here. I wasn't aware of this. Thanks for the info!

Works in Rubymine and PHPStorm as well. Little bit fiddly setting this up Rubymine, have to let the IDE install the debugging gems IIRC.

I also prefer to edit on my local machine but I still prefer terminal vim, I'd rather not have the environment import my settings because I work in a team and don't want to fight with them over the one true config.

If your team is checking in to the central repository such personal things as config files for development environments, you've got bigger problems. Sure, occasional snippets (such as a .dir-locals.el for style), but whole configs? WTF?

The environment is shared for a consistency, if I'm sshing into the environment to do my work then that means I need the environment updated with my config and that either means that we need to share configs on the vagrant user or setup the environment to provision settings for every user of that environment which sounds unmaintainable. It's easier to just work locally through the share directory.

Use can easily do something like this for one-off edits "vim scp://remoteuser@server.tld//path/to/document" or use netrw for a more robust solution to using your local vim to edit remotly. http://www.drchip.org/astronaut/vim/index.html#NETRW

Or you can just edit within the shared directory between your local machine and the environment.

How do multiple monitor setups work with vagrant? (I've had trouble with big IDEs and X transport before, with things just slow enough to irritate me.)

Vagrant VMs are headless. So when you 'vagrant up' a box you won't see a GUI window or anything you'd expect to see when launching VMs with VirtualBox.

Reply on news.ycombinator.com