v0.9.0

Improvements

• Allow using $VIRTUALGO_ROOT to set the directory where environments are stored. By default this is still ~/.virtualgo

Fixes

• Return status code in the PROMPT_COMMAND
• Don't set the same prompt_command if it's already there.

v0.8.0 - Scripting support, binaries and tests

Improvements

• Scripting with vg is now much better supported. vg should now keep working even when you have run set -eux before.
• Starting with this release binaries for some architectures are precompiled, in case you want to pin a specific version of vg for your CI.
• A test suite with coverage is now run on Travis. This should give more confidence that changes don't break vg.
• Some error messages have been improved with much more detailed steps that should be tried to fix the issue.

Fixes

• Ctrl+C during vg ensure now actually kills dep as well #28
• Fix bindfs support on some OSX versions #27
• Some README improvements.

v0.7.2

• Fix issues caught by shellcheck

v0.7.1

• Fixed an issue in using bindfs on OSX

v0.7.0: bindfs support and (re-)changing a bad default

First of all if you don't know what vg is yet, just check the README, which is much more informative in that case. Otherwise these release notes contain the changes to the previous major release of vg that you should know about.

How to upgrade

go get -u github.com/GetStream/vg

Afterwards, restart all your shells to make sure it's using the updated version.

Changes

bindfs support

The main cause of issues with vg is its usage of symbolic links. These are not supported well by go tooling (golang/go#15507, golang/go#17451). For this reason bindfs support has been added, which removes all of the issues caused by having symbolic links in your GOPATH. To use this you have to install bindfs though:

# OSX
brew install bindfs
# Ubuntu
apt install bindfs
# Arch Linux
pacaur -S bindfs  # or yaourt or whatever tool you use for AUR

There's one important thing if you do this though. DON'T remove things manually from the ~/.virtualgo directory. Only use vg destroy/vg uninstall, otherwise you can very well lose data.

Global fallback import mode is the default again

Support for full isolation was added in the previous version (v0.6.0). This was made the default, because it seemed like a really useful feature. However, after more usage by more people it turned out that some things stopped working as expected. Since one of the main goals of vg is that you should be able to use your tools as before this was considered a big issue.

The worst of these issues were caused by the usage of symbolic links, which are thus fixed now. Sadly, some others remained present. Luckily, the remaining issues have simple workarounds. However, without knowing about the issues confusion will likely occur as some common commands don't work as expected. This was still considered a big enough issue that the default for new workspaces has been reverted to "global fallback" import mode. A more thorough explanation of the issues and workarounds can be found in this section of the README.

One important thing to keep in mind is that existing workspaces won't be changed automatically. If you want to use the new default for existing workspaces you should recreate them:

vg destroy example
vg activate example

If after reading the section from the README you still want to use full isolation, you should create new workspaces with the --full-isolation flag as described there.

Small changes

Other than these big changes there's also some small improvements:

• vg destroy now works without arguments when inside a workspace. It will destroy the current workspace in that case.
• vg destroy deactivates the current workspace if it was destroyed.
• When creating a new workspace the output contains the import mode that the new workspace uses.