Virtualgo: Easy and powerful workspace based development for go

virtualgo Build Status codecov Go Report Card

Virtualgo (or vg for short) is a tool which provides workspace based development for Go. Its main feature set that makes it better than other solutions is as follows:

  1. Extreme ease of use
  2. No interference with other go tools
  3. Version pinning for imports
  4. Version pinning for executables, such as linters (e.g. errcheck) and codegen tools (e.g. protoc-gen-go)
  5. Importing a dependency that's locally checked out outside of the workspace (also called multi project workflow)
  6. Optional full isolation for imports, see the section on import modes for details.

Virtualgo doesn't do dependency resolution or version pinning itself, because this is a hard problem that's already being solved by other tools. Its approach is to build on top of these tools, such as dep, to provide the features features listed above. For people coming from Python vg is very similar to virtualenv, with dep being respective to pip. The main difference is that vg is much easier to use than virtualenv, because there's almost no mental overhead in using vg.

Go Modules

The Go community is now using Go Modules to handle dependencies. This project is now mostly unmaintained. Please read more about this here.

Example usage

Below is an example showing some basic usage of vg. See further down and vg help for more information and examples.

$ cd $GOPATH/src/github.com/GetStream/example
$ vg init  # initial creation of workspace

# Now all commands will be executed from within the example workspace
(example) $ go get github.com/pkg/errors # package only present in workspace
(example) $ vg ensure  # installs the dependencies of the example project using dep
(example) $ vg deactivate

$ cd ~
$ cd $GOPATH/src/github.com/GetStream/example
(example) $ # The workspace is now activated automatically after cd-ing to the project directory

Advantages over existing solutions

The obvious question is: Why should you use vg? What advantages does it bring over what you're using now? This obviously depends on what you're using now:

Advantages over vendor directory

  1. You can pin versions of executable dependencies, such as linting and code generation tools.
  2. No more issues with go test ./... running tests in the vendor directory when using go 1.8 and below.
  3. You can easily use a dependency from your global GOPATH inside your workspace, without running into confusing import errors.
  4. It has optional full isolation. If enabled there's no accidental fallbacks to regular GOPATH causing confusion about what version of a package you're using.
  5. When using full isolation, tools such as IDEs can spend much less time on indexing. This is simply because they don't have to index the packages outside the workspace.
  6. You don't have problems when using plugins: https://github.com/akutz/gpd

Advantages over manually managing multiple GOPATHs

  1. Automatic activation of a GOPATH when you cd into a directory.
  2. Integration with version management tools such as dep and glide allow for reproducible builds.
  3. Useful commands to manage installed packages. For instance for uninstalling a package or installing a local package from another GOPATH.

Installation

First install the package:

go get -u github.com/GetStream/vg

Although not required, it is recommended to install bindfs as well. This gives the best experience when using full isolation and when using vg localInstall. If you do this, DON'T remove things manually from ~/.virtualgo. Only use vg destroy/vg uninstall, otherwise you can very well lose data.

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

Automatic shell configuration

You can run the following command to configure all supported shells automatically:

vg setup

After this you have to reload (source) your shell configuration file:

source ~/.bashrc                   # for bash
source ~/.zshrc                    # for zsh
source ~/.config/fish/config.fish  # for fish

Manual shell configuration

You can also edit your shell configuration file manually. Afterwards you still have to source the file like explained above.

For bash put this in your ~/.bashrc file:

command -v vg >/dev/null 2>&1 && eval "$(vg eval --shell bash)"

Or for zsh, put his in your ~/.zshrc file:

command -v vg >/dev/null 2>&1 && eval "$(vg eval --shell zsh)"

Or for fish, put this in your ~/.config/fish/config.fish file:

command -v vg >/dev/null 2>&1; and vg eval --shell fish | source

Usage

The following commands are the main commands to use vg:

# The first command to use is the one to create and activate a workspace named
# after the current direcory
$ cd $GOPATH/src/github.com/GetStream/example
$ vg init
(example) $
# This command also links the current directory to the created workspace. This
# way the next time you cd to this directory the workspace will be activated
# automatically.
# (See below in the README on how to use the workspace from an IDE)

# All go commands in this shell are now executed from within your workspace. The
# following will install the most recent version of the cobra command and
# library inside the workspace
(example) $ go get -u github.com/spf13/cobra/cobra
(example) $ cobra
Cobra is a CLI library for Go that empowers applications.
......

# It's also possible to only activate a workspace and not link it to the
# current directory. If the workspace doesn't exist it will also be
# created on the fly. Activating a new workspace automatically deactivates
# a previous one:
(example) $ vg activate example2
(example2) $ cobra
bash: cobra: command not found

# To deactivate the workspace simply run:
(example2) $ vg deactivate
$ vg activate
(example) $

# When a workspace is active, a go compilation will try to import packages
# installed from the workspace first. In some cases you might want to use the
# version of a package that is installed in your global GOPATH though. For
# instance when you are fixing a bug in a dependency and want to test the fix.
# In these cases you can easily install a package from your global GOPATH
# into the workspace:
(example) $ vg localInstall github.com/GetStream/utils
# You can even install a package from a specific path:
(example) $ vg localInstall github.com/GetStream/utils ~/weird/path/utils

# You can also uninstall a package from your workspace again
(example) $ vg uninstall github.com/spf13/cobra
# NOTE: At the moment this only removes the sources and static libs in pkg/, not
# executables. So the cobra command is still available.

# See the following sections for integration with dependency management tools.
# And for a full overview of all commands just run:
(example) $ vg help
# For detailed help of a specific command run:
(example) $ vg help <command>

dep integration

vg integrates well with dep (https://github.com/golang/dep):

# Install the dependencies from Gopkg.lock into your workspace instead of the
# vendor directory
vg ensure

# Pass options to `dep ensure`
vg ensure -- -v -update

It also extends dep with a way to install executable dependencies. The vg repo itself uses it to install the go-bindata and cobra command. It does this by adding the following in Gopkg.toml:

required = [
    'github.com/jteeuwen/go-bindata/go-bindata',
    'github.com/spf13/cobra/cobra'
]

Running vg ensure after adding this will install the go-bindata and cobra command in the GOBIN of the current workspace.

As you just saw vg reuses the required list from dep. However, if you don't want to install all packages in the required list you can achieve that by putting the following in Gopkg.toml:

[metadata]
install-required = false

You can also specify which packages to install without the required list:

[metadata]
install = [
    'github.com/jteeuwen/go-bindata/go-bindata',
    'github.com/golang/mock/...', # supports pkg/... syntax
]

Integration with other dependency management tools (e.g glide)

Even though dep is the main tool that virtualgo integrates with. It's also possible to use other dependency management tools instead, as long as they create a vendor directory. Installing executable dependencies is not supported though (PRs for this are welcome).

To use vg with glide works like this:

# Install dependencies into vendor with glide
glide install

# Move these dependencies into the workspace
vg moveVendor

Workspace import modes

A workspace can be set up in two different import modes, global fallback or full isolation. The import mode of a workspace determines how imports from code behave and it is chosen when the workspace is created.

Global fallback

In global fallback mode, packages are imported from the original GOPATH when they are not found in the workspace. This is the default import mode for newly created workspaces, as this interferes the least with existing go tools.

Full isolation

In full isolation mode, package imports will only search in the packages that are installed inside the workspace. This has some advantages:

  1. Tools such as IDE's don't have to search the global GOPATH for imports, which can result in a significant speedup for operations such as indexing.
  2. You always know the location of an imported package.
  3. It's not possible to accidentally import of a package that is not managed by your vendoring tool of choice.

However, there's also some downsides to full isolation of a workspace. These are all caused by the fact that the project you're actually working on is not inside your GOPATH anymore. So normally go would not be able to find any imports to it. This is partially worked around by locally installing the project into your workspace, but it does not fix all issues.

In the sections below the remaining issues are described and you can decide for yourself if the above advantages are worth the disadvantages. If you want to try out full isolation you can create a new workspace using the --full-isolation flag:

$ vg init --full-isolation
# To change an existing workspace, you have to destroy and recreate it
$ vg destroy example
$ vg activate example --full-isolation

This will cause the workspace to use full isolation import mode each time it is activated in the future. So there's no need to specify the --full-isolation flag on each activation afterwards.

With bindfs installed

If you have bindfs installed the issues you will run into are only a slight inconvenience, for which easy workarounds exist. However, it is important that you know about them, because they will probably cause confusion otherwise. If you run into any other issues than the ones mentioned here, please report them.

Relative packages in commands

The first set of issues happen when using relative reference to packages in commands. Some examples of this are:

  • go list ./... will return weirdly formatted paths, such as _/home/stream/go/src/github.com/GetStream/vg.
  • go test ./..., might cause an init function to be executed twice.
  • go build ./... won't work when an internal package is present in the directory. Here you can expect an error saying use of internal package not allowed.

Luckily, this can all easily be worked around by using absolute package paths for these commands. So for the vg repo you would use the following alternatives:

# go list ./...
go list github.com/GetStream/vg/...
# go test ./...
go test github.com/GetStream/vg/...
# go build ./...
go build github.com/GetStream/vg/...
dep commands

Another issue that pops up is that dep doesn't allow it's commands to be executed outside of the GOPATH. This is not a problem for dep ensure, since you usually use vg ensure, which handles this automatically. However, this is an issue for other commands, such as dep status and dep init. Luckily there's an easy workaround for this as well. You can simply use vg globalExec, to execute commands from your regular GOPATH, which fixes the issue:

vg globalExec dep init
vg globalExec dep status

Without bindfs installed

If bindfs is not installed, symbolic links will be used to do the local install. This has the same issues as described for bindfs, but there's also some extra ones that cannot be worked around as easily. The reason for this is that go tooling does not like symbolic links in GOPATH (golang/go#15507, golang/go#17451).

Compiling will still work, but go list github.com/... will not list your package. Other than that there are also issues when using delve (#11). Because of these issues it is NOT RECOMMENDED to use virtualgo in full isolation mode without bindfs installed.

Using a virtualgo workspace with an IDE (e.g. GoLand)

Because virtualgo is just a usability wrapper around changing your GOPATH for a specific project it is usually quite easy to use it in combination with an IDE. Just check out your GOPATH after activating a workspace and configure the IDE accordingly. Usually if you show your GOPATH you will see two paths separated by a colon:

$ echo $GOPATH
/home/stream/.virtualgo/myworkspace:/home/stream/go

If you can set this full string directly that is fine. For GoLand you have to add the first one first and then the second one.

When using a workspace in full isolation mode it's even easier to set up as there's only one GOPATH set.

$ echo $GOPATH
/home/stream/.virtualgo/myworkspace

License

MIT

Careers @ Stream

Would you like to work on cool projects like this? We are currently hiring for talented Gophers in Amsterdam and Boulder, get in touch with us if you are interested! [email protected]

Owner
Stream
Build scalable newsfeeds, activity streams, chat and messaging in a few hours instead of weeks
Stream
Comments
  • Virtualgo does not work well with delve

    Virtualgo does not work well with delve

    I'm currently using Gogland for go development. Switching over to vg definitely helps with reducing CPU load and in general making gogland snappier.

    Running tests still works as expected. When setting breakpoints and running tests in debug mode, it seems like the breakpoints are not registering at all. My current fallback solution is to set GOPATH back to my default global path, effectively disabling vg, but that defeats the purpose of using it in the first place :)

    This may be an OS X thing and how it deals with symlinks, but I thought I'd see if anyone else has a good way of dealing with this.

  • Allow replacing ~/.virtualgo with VIRTUALGO_ROOT

    Allow replacing ~/.virtualgo with VIRTUALGO_ROOT

    Caveat: only tested under bash. fish code cargo culted from https://unix.stackexchange.com/questions/81421/how-do-i-reference-a-variable-in-fish-shell-with-a-default-fallback and untested.

    Fixes #17.

  • "vg ensure -- -update" does not play well with persisted local packages

    Below github.com/qubit-sh/go-crypto is a persisted package (symlinked from /Users/mmuthanna/.virtualgo/qubit/src/github.com/qubit-sh/go-crypto.)

    $ vg ensure -- -v -update
    Running "dep ensure -v -update"
    Root project is "github.com/qubit-sh/xpoller"
     1 transitively valid internal packages
     2 external packages imported from 2 projects
    (0)   ✓ select (root)
    (1)     ? attempt github.com/qubit-sh/go-crypto with 1 pkgs; 1 versions to try
    (1)         try github.com/qubit-sh/go-crypto@master
    
    <SNIP>
    
    Uninstalling "github.com/qubit-sh/go-crypto" from workspace
      Removing sources at "/Users/mmuthanna/.virtualgo/qubit/src/github.com/qubit-sh/go-crypto"
    Error: Couldn't move the vendor directory to the active workspace: rename vendor /Users/mmuthanna/.virtualgo/qubit/src: no such file or directory
    Usage:
      vg ensure [-- [arguments to dep ensure]] [flags]
    
    Flags:
      -h, --help   help for ensure
    
    Couldn't move the vendor directory to the active workspace: rename vendor /Users/mmuthanna/.virtualgo/qubit/src: no such file or directory
    

    The workaround is to call vg ensure immediately after to relink the persistent package.

  • With --full-isolation, package fails to import its own internal packages

    With --full-isolation, package fails to import its own internal packages

    Here's a simplified example: (hello) callpraths@remote-workstation:/mnt/work/go/src/hello$ tree

    .
    ├── hello
    ├── hello.go
    └── internal
        └── hello2
            └── hello2.go
    

    (hello) callpraths@remote-workstation:/mnt/work/go/src/hello$ cat internal/hello2/hello2.go package hello2

        import (
                "fmt"
        )
    
        func Do() {
                fmt.Println("hello2")
        }
    

    (hello) callpraths@remote-workstation:/mnt/work/go/src/hello$ vim hello.go (hello) callpraths@remote-workstation:/mnt/work/go/src/hello$ cat hello.go

        package main
        import (
                "hello/internal/hello2"
        )
    
        func main() {
            hello2.Do()
        }
    

    Without vg: callpraths@remote-workstation:/mnt/work/go/src/hello$ go run hello.go hello2

    With vg (but fallback to GOPATH): callpraths@remote-workstation:/mnt/work/go/src/hello$ vg init Creating workspace "hello" with global fallback import mode Activating hello Linking /mnt/work/go/src/hello to workspace 'hello' (hello) callpraths@remote-workstation:/mnt/work/go/src/hello$ go run hello.go hello2

    With vg (full isolation): (hello) callpraths@remote-workstation:/mnt/work/go/src/hello$ vg destroy Destroying workspace "hello" Deactivating hello callpraths@remote-workstation:/mnt/work/go/src/hello$ vg init --full-isolation Creating workspace "hello" with full isolation import mode Installing local sources at "/mnt/work/go/src/hello" in workspace as "hello" using bindfs Persisting the local install for "hello" Activating hello Uninstalling "hello" from workspace Unmounting bindfs mount at "/home/callpraths/.virtualgo/hello/src/hello" Removing sources at "/home/callpraths/.virtualgo/hello/src/hello" Installing local sources at "/mnt/work/go/src/hello" in workspace as "hello" using bindfs Persisting the local install for "hello" Linking /mnt/work/go/src/hello to workspace 'hello' (hello) callpraths@remote-workstation:/mnt/work/go/src/hello$ go run hello.go hello.go:4:2: use of internal package not allowed

  • vg environment name does not display in the zsh

    vg environment name does not display in the zsh

    Hi,

    I'm using POWERLEVEL9K theme on zsh. When I activate a virtual environment, the theme doesn't change to show the name of the current environment. I sometimes forgot to deactivate it. How to set up zsh for showing the name of activated environment?

    thanks

    P.S: I'm using OSX and my zsh is the latest version.

  • sh: clean up some issues caught by shellcheck

    sh: clean up some issues caught by shellcheck

    The most important bits here are quoting the $@ invocations, especially in vg globalExec; without this, trying to pass arguments containing spaces to the program exec'd by vg globalExec will fail. Some other instances are helpful if your home directory has a space in its path. Some of the other quotes are perhaps extraneous (eg, with echo), but it's a good habit to be in anyway.

  • vg ensure -- -dry-run results in a not very useful error

    vg ensure -- -dry-run results in a not very useful error

    With dep -dry-run no vendor directory is created which vg ensure expects. A clearer error for this would be good, but actual behaviour should stay basically the same.

  • Editing other packages

    Editing other packages

    The VG version of pip install -e . isn't clearly explained. Say that I'm working on a package and want to clone and edit one of the dependencies, how do i do that with VG?

    Tommaso showed me one solution, we should document it.

  • go-plus plugin cannot find virtualgo installed packages

    go-plus plugin cannot find virtualgo installed packages

    I'm using Atom and go-plus plugin. After I installed grpc package, the go-plus showed the following error:

    main.go:8:2: cannot find package "google.golang.org/grpc" in any of:
    /usr/local/opt/go/libexec/src/google.golang.org/grpc (from $GOROOT)
    /[mypath]/src/google.golang.org/grpc (from $GOPATH)
    

    but I can run it in the terminal without any error:

    go run main.go
    
  • Breaks when initial GOPATH is empty

    Breaks when initial GOPATH is empty

    When I activate a workspace using vg while my GOPATH is empty, the new GOPATH ends in a colon, followed by the original empty GOPATH, which confuses go:

    matthijs@grubby:/$ cd /path/to/bar/
    Activating bar
    Uninstalling "github.com/foo/bar" from workspace
      Unmounting bindfs mount at "/home/matthijs/.virtualgo/bar/src/github.com/foo/bar"
      Removing sources at "/home/matthijs/.virtualgo/bar/src/github.com/foo/bar"
      Removing "github.com/foo/bar" from locally installed packages
    Installing local sources at "." in workspace as "github.com/foo/bar" using bindfs
    (bar) matthijs@grubby:/path/to/bar$ echo $GOPATH
    /home/matthijs/.virtualgo/bar:
    (bar) matthijs@grubby:/path/to/bar$ go build
    go: GOPATH entry is relative; must be absolute path: "".
    For more details see: 'go help gopath'
    

    I realize that using a fully-isolated workspace would work here, but would it perhaps make sense to just ignore the previous GOPATH if it is empty?

  • Publish binary executable of vg?

    Publish binary executable of vg?

    dep publish binary executable on GitHub for each version. It would be great if vg can do the same too. This allows installation specific version of vg in CI or via homebrew.

    dep build the executables using travis. There travis script is here: https://github.com/golang/dep/blob/master/.travis.yml

  • vg auto-activate works incorrectly

    vg auto-activate works incorrectly

    Case 1: Destroyed environments are re-created again with cd

    [host]xyz_proj$ vg init
    ...
    (xyz_proj) [host]xyz_proj$ vg destroy
    [host]xyz_proj$ cd any_other_folder
    [host]any_other_folder$ cd xyz_proj
    Creating workspace "xyz_proj" with global fallback import mode
    Activating "xyz_proj"
    (xyz_proj) [host]xyz_proj$
    

    I've managed to fix the problem with new condition to activate function:

    __vg_auto_activate() {
        activation_root=$PWD
        while [ "$activation_root" != "" ]; do
            if [ -f "$activation_root/.virtualgo" ]; then
                new_virtualgo_name=$(cat "$activation_root/.virtualgo")
                if [ "" = "$VIRTUALGO" ] || [ "$new_virtualgo_name" != "$VIRTUALGO" ]; then
                    # that's what I added
                    if [[ -d "$HOME/.virtualgo/$new_virtualgo_name" ]];then   # <=========
                    vg activate "$new_virtualgo_name"
                    fi
                fi
                return
    

    Also, I think that vg destroy should do vg unlink automatically

    Case 2: Activate in child folder of folder that is linked to some vg environment will create new environment instead of activating parent.

    src is a child folder of goenv:

    (goenv) [host]src$ vg deactivate
    Deactivating goenv
    [host]src$ vg activate
    Creating workspace "src" with global fallback import mode
    Activating src
    
  • 'vg ensure' fails when project directory and home directory are located on different devices

    'vg ensure' fails when project directory and home directory are located on different devices

    Command vg ensure run within the project directory and activated workspace returns:

    (project) [user@machine project][✔]$ vg ensure
    Running "dep ensure"
    Error: Couldn't move the vendor directory to the active workspace: rename vendor /home/user/.virtualgo/project/src: invalid cross-device link
    Usage:
      vg ensure [-- [arguments to dep ensure]] [flags]
    
    Flags:
      -h, --help   help for ensure
    
    Couldn't move the vendor directory to the active workspace: rename vendor /home/uservirtualgo/project/src: invalid cross-device link
    

    This is caused by the fact that my home directory is located on one device (/dev/sdb3) and my project directory on another (/dev/sda1). Call to os.Rename (https://github.com/GetStream/vg/blob/master/cmd/ensure.go#L143) will return a LinkError.

  • Changing workspace breaks fish shell

    Changing workspace breaks fish shell

    When changing from one workspace to another in fish, the prompt updating fails. It's worth noting that I've have a function in my fish config also called fish_prompt:

    https://github.com/karlek/dotfiles/blob/master/.config/fish/conf.d/08-prompt.fish

    (gateway) (^._.^)ノ elysium @ /home/_/.local/share/go/src/github.com/karlek/tf/gateway $ ../keysmith/
    Deactivating gateway
    functions: Function “fish_prompt” already exists. Cannot create copy “_old_fish_prompt”
    - (line 109): 
            functions -c _old_fish_prompt fish_prompt
            ^
    in function “_vg_deactivate”
    	called on line 46 of file -
    
    in function “_vg_activate”
    	called on line 13 of file -
    	with parameter list “activate keysmith”
    
    in function “vg”
    	called on line 189 of file -
    	with parameter list “activate keysmith”
    
    in function “__vg_auto_activate”
    	called on line 5 of file /usr/share/fish/functions/cd.fish
    	with parameter list “VARIABLE SET PWD”
    
    in event handler: handler for variable “PWD”
    
    
           functionsfunctions - print or erase functions
            -
    
       Synopsis
           functions [ -a | --all ] [ -n | --names ]
           functions [ -D | --details ] [ -v ] FUNCTION
           functions -c OLDNAME NEWNAME
           functions -d DESCRIPTION FUNCTION
           functions [ -e | -q ] FUNCTIONS...
    
    functions: Type “help functions” for related documentation
    
    Activating keysmith
    (keysmith) _@elysium ~/.l/s/g/s/g/k/t/keysmith>
    
  • Relative paths passed to localInstall work unexpectedly

    Relative paths passed to localInstall work unexpectedly

    I'm a bit stubborn when it comes to go and directory organisation, so I tried to use vg to create a git clone of my project in whatever directory I wanted (without having to have it in src/github.com/foo/bar). I was hoping that that would take care of creating a virtual GOPATH somewhere, and automatically link my project directory into there in an appropriate place. Unfortunately that did not happen, so I needed a manual vg localInstall to get my project directory linked (which makes sense, since vg does not know the full package name of my project).

    So, I tried:

    /path/to/bar$ vg localInstall github.com/foo/bar .
    /path/to/bar$ mount|grep bar
    /path/to/bar on /home/matthijs/.virtualgo/bar/src/github.com/foo/bar type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions)
    

    Which indeed correctly puts /path/to/bar in the virtual $GOPATH/src/github.com/foo/bar. However, in virtualgo.toml it stores the original relative path ., and it seems this path is interpreted relative to the current directory, not the project root. E.g. if I deactivate the workspace and then jump into a subdirectory of my project, things get broken:

    /$ cd /path/to/bar/sub/ Activating bar Uninstalling "github.com/foo/bar" from workspace Unmounting bindfs mount at "/home/matthijs/.virtualgo/bar/src/github.com/foo/bar" Removing sources at "/home/matthijs/.virtualgo/bar/src/github.com/foo/bar" Removing "github.com/foo/bar" from locally installed packages Installing local sources at "." in workspace as "github.com/foo/bar" using bindfs (bar) matthijs@grubby:/path/to/bar/sub$ mount|grep bar /path/to/bar/sub on /home/matthijs/.virtualgo/bar/src/github.com/foo/bar type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions)

    Should the path passed to localInstall be made absolute before storing it?

  • How do I pin the version of executables?

    How do I pin the version of executables?

    There seems to be no writeup on this matter in the documentations (aka README). I'm using vg with dep and my current way of installing executables is putting them in required field inside Gopkg.toml

A powerful modern CLI and SHELL
A powerful modern CLI and SHELL

Grumble - A powerful modern CLI and SHELL There are a handful of powerful go CLI libraries available (spf13/cobra, urfave/cli). However sometimes an i

Dec 30, 2021
Mcli - A mininal and very powerful cli library for Go

mcli mcli is a minimal but powerful cli library for Go. m stands for minimal and

Nov 18, 2022
🚀 Platform providing a powerful and fast public script parsing API dedicated to the Skript community.

SkriptMC-Parser is currently a prototype in the early stages of development of a system that allows the Skript community to test their scripts via a public API for potential errors or warnings. This is a quick and easy way to check your scripts without having to set up a Spigot server on your environment.

Mar 3, 2022
Flag is a simple but powerful command line option parsing library for Go support infinite level subcommand

Flag Flag is a simple but powerful commandline flag parsing library for Go. Documentation Documentation can be found at Godoc Supported features bool

Sep 26, 2022
`tmax` is a powerful tool to help you get terminal cmd directly.
`tmax`  is a powerful tool to help you get terminal cmd directly.

The positioning of tmax is a command line tool with a little artificial intelligence. If you frequently deal with the terminal daily, tmax will greatly improve your work efficiency.

Oct 15, 2022
A powerful cli tool to implement gin annotation ⭐
A powerful cli tool to implement gin annotation ⭐

gin-annotation A powerful cli tool to implement gin annotation Chinese Document Features Using code generating technology by operating golang AST Rout

Mar 24, 2022
Building powerful interactive prompts in Go, inspired by python-prompt-toolkit.
Building powerful interactive prompts in Go, inspired by python-prompt-toolkit.

go-prompt A library for building powerful interactive prompts inspired by python-prompt-toolkit, making it easier to build cross-platform command line

Jan 3, 2023
A powerful little TUI framework 🏗
A powerful little TUI framework 🏗

Bubble Tea The fun, functional and stateful way to build terminal apps. A Go framework based on The Elm Architecture. Bubble Tea is well-suited for si

Dec 27, 2022
Powerful CLI written in GO to generate projects in various technologies
Powerful CLI written in GO to generate projects in various technologies

Barca CLI is a project generator written in GO and its purpose is to build and configure HTTP servers, web proxy, SPA/PWA, Blog and custom landing page. It's easy, fast and productive.

Aug 26, 2022
A lightweight but powerful OCR tool.
A lightweight but powerful OCR tool.

这个项目是什么? LOCR(Lightweight OCR)是一款轻量级的文字识别工具, 结合第三方截图工具, 可以快速的对图片文字进行识别。 为什么有这个项目 在日常学习的工作中, 难免会遇到一些文字的复制粘贴任务。但由于一些限制,我们无法复制想要的文字,只能一个字一个字的敲出来。而随着近几年OC

Nov 1, 2022
Bofin - A command line tool that can be used by to make Weblink development more productive

Bofin A command line tool that can be used by to make Weblink development more p

Jan 13, 2022
Dev-spaces - A CLI to help creating development environments using AWS Spot Instances

This is a CLI to help creating on-demand development spaces using EC2 Spot Intances.

Nov 9, 2022
Small CLI based programs for solving structural engineering design problems based on the book 'Structural Concrete'

Small CLI based programs for solving structural engineering design problems based on the book 'Structural Concrete' written by M. Nadim Hassoun and Akhtem Al-Manaseer (edition-6)

Nov 26, 2021
Simple and easy to use command line application written in Go for cleaning unnecessary XCode files.

xcclear Say hello to a few extra gigabytes of space on your Mac with xcclear, a simple and easy to use command line application written in Go for clea

Dec 16, 2022
A go library for easy configure and run command chains. Such like pipelining in unix shells.

go-command-chain A go library for easy configure and run command chains. Such like pipelining in unix shells. Example cat log_file.txt | grep error |

Dec 27, 2022
Go binding configuration and command flag made easy✨✨
Go binding configuration and command flag made easy✨✨

✨ Binding configuration and command flag made easy! ✨ You can use multiple keys tag to simplify the look like this (supported feature**): // single ta

Sep 18, 2022
It is an easy and fast tool to install your packages with just one command.

Trouxa It is an easy and fast tool to install your packages with just one command. What means "Trouxa"? In portuguese, Trouxa means something like a "

Sep 29, 2022
Portal is a quick and easy command-line file transfer utility from any computer to another 🖥️ 🌌 💻
Portal is a quick and easy command-line file transfer utility from any computer to another 🖥️ 🌌 💻

Portal is a quick and easy command-line file transfer utility from any computer to another ??️ ?? ??

Dec 27, 2022
Easy to use library and CLI utility to generate Go struct from CSV files.

csv2struct Easy to use library and CLI utility to generate Go struct from CSV files. As a benefit, it's fully compatible with csvutil. So, structs gen

Nov 7, 2022