a Make/rake-like dev tool using Go

Overview

Built with Mage Build Status Build status

About

Mage is a make-like build tool using Go. You write plain-old go functions, and Mage automatically uses them as Makefile-like runnable targets.

Installation

Mage has no dependencies outside the Go standard library, and builds with Go 1.7 and above (possibly even lower versions, but they're not regularly tested).

Using GOPATH

go get -u -d github.com/magefile/mage
cd $GOPATH/src/github.com/magefile/mage
go run bootstrap.go

Using Go Modules

git clone https://github.com/magefile/mage
cd mage
go run bootstrap.go

This will download the code and then run the bootstrap script to build mage with version infomation embedded in it. A normal go get (without -d) or go install will build the binary correctly, but no version info will be embedded. If you've done this, no worries, just go to $GOPATH/src/github.com/magefile/mage and run mage install or go run bootstrap.go and a new binary will be created with the correct version information.

The mage binary will be created in your $GOPATH/bin directory.

You may also install a binary release from our releases page.

Demo

Mage Demo

Discussion

Join the #mage channel on gophers slack or post on the magefile google group for discussion of usage, development, etc.

Documentation

see magefile.org for full docs

see godoc.org/github.com/magefile/mage/mage for how to use mage as a library.

Why?

Makefiles are hard to read and hard to write. Mostly because makefiles are essentially fancy bash scripts with significant white space and additional make-related syntax.

Mage lets you have multiple magefiles, name your magefiles whatever you want, and they're easy to customize for multiple operating systems. Mage has no dependencies (aside from go) and runs just fine on all major operating systems, whereas make generally uses bash which is not well supported on Windows. Go is superior to bash for any non-trivial task involving branching, looping, anything that's not just straight line execution of commands. And if your project is written in Go, why introduce another language as idiosyncratic as bash? Why not use the language your contributors are already comfortable with?

Thanks

If you use mage and like it, or any of my other software, and you'd like to show your appreciation, you can do so on my patreon:

Comments
  • The mage released binary isn't self contained

    The mage released binary isn't self contained

    Resolving deltas: 100% (29367/29367), done.
    Error: failed to check types in directory: magefile.go:14:2: could not import github.com/magefile/mage/mg (cannot find package "github.com/magefile/mage/mg" in any of:
    	/go/src/github.com/gohugoio/hugo/vendor/github.com/magefile/mage/mg (vendor tree)
    	/usr/local/go/src/github.com/magefile/mage/mg (from $GOROOT)
    	/go/src/github.com/magefile/mage/mg (from $GOPATH))
    Exited with code 1
    

    And while I do understand the error above and know the workaround for it, I did expect this to just work without any "go getting". I guess the released binary is just for bootstrapping and not really something one can use for added stability?

    Having it in my vendor file would not work either (chicken and egg).

    :computer: UX 
    opened by bep 37
  • auto-args for targets?

    auto-args for targets?

    It wouldn't be too hard to auto-generate a CLI for each target so the user could pass in positional args or flags per arg.

    e.g.

    func Build(OS string, ARCH string) error {
         // build with GOOS and GOARCH
    }
    
    $ mage build -os darwin -arch amd64
    building with GOOS=darwin GOARCH=amd64
    
    :rocket: future-maybe 
    opened by natefinch 28
  • Mage fails to locate transient dependencies saved via Go modules

    Mage fails to locate transient dependencies saved via Go modules

    It looks like Mage doesn't fully support dependencies defined by Go modules. In particular, transient dependencies fail because they're not placed in the place that Mage expects.

    To reproduce, create a new project containing a dependency, followed by a Magefile that uses it:

    $ go mod init app
    $ go get golang.org/x/text/unicode/norm
    
    // +build mage
    
    package main
    
    import (
            "golang.org/x/text/unicode/norm"
    )
    
    func Test() {
            print("unicode version: " + norm.Version)
    }
    

    Running mage test fails with the following error:

    Error: failed to check types in directory: magefile.go:6:2: could not import golang.org/x/text/unicode/norm (type-checking package "golang.org/x/text/unicode/norm" failed (/home/damien/go/pkg/mod/golang.org/x/[email protected]/unicode/norm/normalize.go:15:2: could not import golang.org/x/text/transform (cannot find package "golang.org/x/text/transform" in any of:
            /usr/local/go/src/golang.org/x/text/transform (from $GOROOT)
            /home/damien/go/src/golang.org/x/text/transform (from $GOPATH))))
    

    This is because golang.org/x/text/unicode/norm depends on golang.org/x/text/transform, which exists, but not in the GOPATH. Using modules, Go downloads both dependencies to ~/go/pkg/mod/golang.org/x/[email protected]/.

    Mage should be updated to include the logic utilized by e.g. go list -m -f '{{.Dir}}' all to locate modularized dependencies, if being compiled with Go 1.11 or later.

    opened by dradtke 22
  • Added support for per target CLI flags/params

    Added support for per target CLI flags/params

    Hello Guys,

    I’ve been using Mage for more than a month now, for some serious work and I can say it works brilliantly.

    In the past I was using a lot of Make and the only thing I'm missing from Make in Mage is the ability to pass arguments to targets.

    For example, in Makefile I can do something like this:

    ARG=
    target:
         action $(ARG)
    

    and then call it from CLI like:

    make target ARG=foo
    

    I know I can use environmental variables for it and it works, but in my opinion it's a bit counter-intuitive when you want to build a nice tool using Mage which will allow user to work in natural fashion by first typing a command name and then feeding it with some arguments/params.

    Clearly I'm not the only one who is missing this feature (according to these posts):

    https://github.com/magefile/mage/issues/24 https://github.com/magefile/mage/issues/24#issuecomment-424758830

    Over the weekend I came up with my own solution to this problem. At first I was trying simply to obtain args using os.Args at target "scope" but it didn't work, as all of passed args were removed, and also immediately I was given errors about mismatched target names (because args passed to targer were interpreted as targets names obviously).

    After some reverse engineering I found out that at Mage code-level all args are delivered by the os nicely, but they get removed during Mage initial processing.

    So in my solution I modified the template.go file in order to prevent arguments removal and also to prevent error about "unknown targets" so that passed args are no longer interpreted as targets names.

    Each processed argument gets marked with prefixes based on the name of target which was preceding it. Because targets args are coming after targets names, we can know which args belong to which target. Also, my code is dealing correctly with target aliases; aliases are resolved to full original target name and stored as such in a prefix instead. Those names have to later match with caller function detection (more about this later).

    The following flags format are supported:

    // --                                          : stop processing any further arguments
    // -f --f -flag --flag                         : boolean flags only
    // -f=value --f=value -flag=value --flag=value : boolean, integer, string flags
    // f=value flag=value                          : boolean, integer, string flags (read above below note)
    

    Those formats are matched using below RegEx:

    (^\w+\=\S*)|(^-{1,2}\w+\=\S*)|(^-{1,2}\w+$)
    

    (it can be validated here: https://regex101.com/)

    Given that we have three targets:

    new
    build
    run
    

    General format:

    mage target1 [FLAGS] target2 [FLAGS] ...
    

    examples:

    mage target1 --boolean-flag --long-flag=abc -r=30 -v target2 --some-other-value="5a23d6eb3bdbcd6" -vv var=123
    
    mage new
    mage new --name=banana --input='/some/path/to/file.ext' --enabled -r
    mage new --name=banana --input='/some/path/to/file.ext' --enabled -r build stage=dev -n=3 run
    

    There is also support provided for -- which is causing Mage to stop processing any further CLI arguments or running any further targets: in the following example, only new and build target will be called, and build will only get stage argument, but not n argument for example.

    (Note: please notice -- after stage=dev)

    mage new --name=banana --input='/some/path/to/file.ext' --enabled -r build stage=dev -- -n=3 run
    

    Some examples:

    -f
    -1
    -flag
    --f
    --1
    --flag
    -a="/path/to/file" --nextFlag
    -1="/path/to/file"
    -flag="/path/to/file"
    --a="/path/to/file"
    --1="/path/to/file"
    --flag="/path/to/file"
    -f=
    -1=
    -f=3 --nextFlag
    -1=abc
    -flag=cheese
    --f=
    --f=300millions
    --1=awesomeness
    --flag="/path/to/file"
    var=
    var=some
    other_var=something
    

    These cases are ignored by this RegEx:

    -
    --
    target
    another_target
    ---b
    ---banana
    

    Processing args at example "New" target

    In the below snippet the crucial part of the way it works is this function call:

    mg.GetArgsForTarget()
    

    This function is checking callstack and finds out the name of the caller function, then it's checking all CLI args available at os.Args and finds those which contains caller function name in it (e.g.: main.new: ). Then it returns the list of all those found args as strings array which can then be processed by flags package as follows:

    mage new --name=banana --input='/some/path/to/banana.jpg' --enabled -r=30
    
    type NewOptions struct {
        Name    string
        Input   string
        Enabled bool
        R       int
    }
    
    func New() {
        var defaultOptions NewOptions
        options := defaultOptions
        //----------------------------
        // Here we call our args filtering
        // function, which will give us
        // only arguments applying to "New" target
        //----------------------------
        args := mg.GetArgsForTarget()
        //----------------------------
        // process args using flags package, and do whatever you want
        fs := flag.NewFlagSet("mytool new", flag.ExitOnError)
        fs.StringVar(&options.Name, "name", "models", "resource name")
        fs.StringVar(&options.Name, "n", "models", "resource name")
        fs.StringVar(&options.Input, "input", "", "resource path")
        fs.StringVar(&options.Input, "i", "", "resource path")
        fs.BoolVar(&options.Enabled, "enabled", false, "something is enabled")
        fs.BoolVar(&options.Enabled, "e", false, "something is enabled")
        fs.IntVar(&options.R, "r", 0, "radius")
        fs.Parse(args)
        //----------------------------
        // Deal with any parsed args
        // as object nicely here
        //----------------------------
        fmt.Println("Created New Project!")
        fmt.Println("Name: ", options.Name)
        fmt.Println("Input: ", options.Input)
    

    ps. I was testing this code a lot, and it's working for me. Let me know what you think about this change and I'll write tests for it :)

    opened by mojzesh 14
  • import targets from another magefile

    import targets from another magefile

    If you have common targets you want to use for multiple magefiles, right now there's no way to share the targets.

    A . import statement could be a good implementation. It's pretty obvious and fairly straightforward to implement.

    import . "example.com/my-mage/std-magefile"

    :sparkles: enhancement 
    opened by natefinch 14
  • Enhancement: support putting magefiles in a subdirectory

    Enhancement: support putting magefiles in a subdirectory

    Describe the feature

    I propose that we add support for a ./magefile subdirectory that could contain all your magefiles without using the mage build tag and without putting the files in package main. Then if you run mage in that directory or the one above it, mage would use the files in that directory as the files to build into the compiled binary.

    What problem does this feature address?

    The major benefit of this is mostly that we stop confusing the language server. Currently, when you write magefiles, you give them the mage build tag, and put them in package main.

    The problem is that the language server won't consider them when it's running in your editor, because the build tag isn't specified. If you DO specify the build tag, then you sometimes will have two different packages in the same directory (whatever package normally exists in the root directory, and then package main for the magefiles).

    If you happen to not have other go code in the root directory or that code is also package main, then it's ok. But if it's not, the language server will barf, because you can't have two packages in the same folder.

    Even if you don't have other go code, the language server still will tend to barf, because you have package main and no func main(){} defined.

    The other benefit is that sometimes it's just nice to have your build/dev scripts squirreled away in a subdirectory, rather that cluttering up your root directory.

    :sparkles: enhancement 
    opened by natefinch 12
  • Error: error compiling magefiles

    Error: error compiling magefiles

    I'm getting a strange error that I don't know how to fix or how to figure out why. System: OS: Windows 10 x64 CPU: Intel Core i7-7500U Go Version: 1.12

    go get -u -d github.com/magefile/mage
    cd $GOPATH/src/github.com/magefile/mage
    go run bootstrap.go   <-- errors out here
    
    go run bootstrap.go
    go build command-line-arguments: mkdir H:: The system cannot find the path specified.
    Error: error compiling magefiles
    exit status 1
    
    opened by milesje 12
  • TestMixedMageImports fail on macOS in modules mode (current master)

    TestMixedMageImports fail on macOS in modules mode (current master)

    Hello.

    Running go test ./... on macOS, commit 5dee1ad6efb4c25f634bda90d11fb5157c80e5e8 gives the following:

    --- FAIL: TestMixedMageImports (0.17s)
        main_test.go:249: expected to exit with code 0, but got 1, stderr: build command-line-arguments: cannot find module for path _/Users/dottedmag/srcs/mage/mage/testdata/mixed_lib_files/subdir
            Error: error compiling magefiles
        main_test.go:254: expected "Targets:\n  build    \n" but got ""
    
    :ant: bug 
    opened by misha-ridge 12
  • Tab completion

    Tab completion

    Mage is so amazing, a breath of fresh air for build tools! Love the minimalism and potential for highly cross-platform builds! Hey, could we get some tab completion for target names? Perhaps a bash completion script?

    :sparkles: enhancement :pray: help wanted 
    opened by mcandre 11
  • ci: migrate from travis to github action

    ci: migrate from travis to github action

    • Add github action workflow (see build results in here, https://github.com/chenrui333/mage/actions)
    • Remove travis as travis does not build the project anymore

    closes #378

    opened by chenrui333 10
  • Feature Request : Prefix returned errors with something such as `Error:`

    Feature Request : Prefix returned errors with something such as `Error:`

    In the video demo your example of return errors.New("boo!") just prints out "boo!" and whilst the echo $? shows a non-zero exit code, there is nothing on the screen to visually show the command failed.

    I know some people have prompts which display something when the previous command failed, however I think it would be nice to show it visually too. Nothing too big, but just big enough.

    For example:

    $ mage install
    Error: boo!
    

    As a comparison let's just look at what make does. We don't have to copy this nor am I holding it up as the ideal, but just a curiosity. For example, if my target just tried to cat a non-existant file:

    $ make target
    cat hello.go
    cat: hello.go: No such file or directory
    Makefile:2: recipe for target 'target' failed
    make: *** [build] Error 1
    

    Which (I think) is made up of the command, stderr from the command and then output from make itself. I'm happy to keep it real simple as above and just prefix the output with Error:.

    (Note: I think we could or should also do the same for functions that don't return errors, so I'm not sure how we'd do that - perhaps if they wrote something on stderr? This comment is a non-goal of this ticket and perhaps another ticket should be opened, however it's pertinent to raise this here in case it impacts what we do here.)

    :sparkles: enhancement :hatching_chick: good first issue 
    opened by chilts 10
  • Enhancement: glob targets

    Enhancement: glob targets

    Describe the feature I think it would be really nifty to be able to use mage in a make-like way with globs. Note: this is perhaps an alternative or enhancement to #340, which would also enable this sort of thing, albeit with a requisite target.

    What problem does this feature address? I am writing a book using asciidoc, and I have targets for generating PDFs for pre-pub and editing. I would like to be able to generate ALL pdfs (target pdfs) or just one at a time mage manuscript/chapter07.pdf. Currently this isn't possible I don't think, however you could provide a way to mark a function (either exported or not) as accepting a certain glob. Maybe something like this:

    func Pdfs() error {
      // get all files
      return pdf(allfiles...)
    }
    
    func pdf(fileTargets ...string) error {
      for _, ft := range fileTargets {
        //...
      }
    }
    
    mg.Globs(pdf, "manuscript/*.pdf)
    
    :sparkles: enhancement 
    opened by flowchartsman 0
  • Bug: Failed to run compiled magefile.

    Bug: Failed to run compiled magefile.

    Bug Description Mage has trouble finding the resulting compiled magefile in my azure devops pipeline. Seems to work fine on multiple local hosts (i.e. for the development team- we're using Win 11). FWIW, the ADO pipeline runs Windows Server 2019 images.

    It looks as though there's an extra '' character slipped into the path when the mage attempts to run the resulting exe? (see further down).

    Unfortunately I don't have a local Windows Server 2019 handy to step through with a debugger (I can try to put one together if more info is required). :(

    What did you do? Install mage, change to the correct directory, mage test:lint (it's the same for any target though)

    What did you expect to happen? I expected mage to run my target, as it does on local hosts.

    What actually happened?

    DEBUG: 08:58:50.114977 found namespace method ./ Build.Foo64
    DEBUG: 08:58:50.114977 found namespace ./ Compile
    DEBUG: 08:58:50.114977 found namespace method ./ Compile.Assets
    DEBUG: 08:58:50.114977 found namespace method ./ Compile.Yella
    DEBUG: 08:58:50.114977 found namespace ./ Dependency
    DEBUG: 08:58:50.114977 found namespace ./ Git
    DEBUG: 08:58:50.114977 found namespace ./ Test
    DEBUG: 08:58:50.114977 found namespace method ./ Test.Checkdependencies
    DEBUG: 08:58:50.114977 found namespace method ./ Test.Foobar
    DEBUG: 08:58:50.114977 found namespace method ./ Test.Foo
    DEBUG: 08:58:50.114977 found namespace method ./ Test.Functional
    DEBUG: 08:58:50.114977 found namespace method ./ Test.Lint
    DEBUG: 08:58:50.114977 found namespace method ./ Test.Precommit
    DEBUG: 08:58:50.114977 found namespace method ./ Test.Race
    DEBUG: 08:58:50.114977 found namespace method ./ Test.Unit
    DEBUG: 08:58:50.114977 found namespace ./ Utils
    DEBUG: 08:58:50.114977 found namespace ./ Winres
    DEBUG: 08:58:50.114977 found target Clean
    DEBUG: 08:58:50.114977 found target Cleaner
    DEBUG: 08:58:50.114977 time parse Magefiles: 2.2189ms
    DEBUG: 08:58:50.115485 Creating mainfile at magefiles\mage_output_file.go
    DEBUG: 08:58:50.115640 writing new file at magefiles\mage_output_file.go
    DEBUG: 08:58:50.118837 compiling to magefile\25aaac15522b215c66ad05db4c827dcfccff724d.exe
    DEBUG: 08:58:50.118837 compiling using gocmd: go
    DEBUG: 08:58:55.576665 running go build -o magefile\25aaac15522b215c66ad05db4c827dcfccff724d.exe dependson.go git.go magefile.go utils.go winres.go mage_output_file.go
    go: downloading [github.com/carolynvs/magex](http://github.com/carolynvs/magex) v0.9.0
    go: downloading [golang.org/x/sys](http://golang.org/x/sys) v0.0.0-20210510120138-977fb7262007
    go: downloading [github.com/Masterminds/semver/v3](http://github.com/Masterminds/semver/v3) v3.1.1
    DEBUG: 08:59:00.885789 time to compile Magefile: 5.3085701s
    DEBUG: 08:59:00.885789 running binary magefile\25aaac15522b215c66ad05db4c827dcfccff724d.exe
    DEBUG: 08:59:00.885789 running magefile with mage vars:
    MAGEFILE_VERBOSE=1
    MAGEFILE_DEBUG=1
    MAGEFILE_GOCMD=go
    failed to run compiled magefile: exec: "magefile\\25aaac15522b215c66ad05db4c827dcfccff724d.exe": file does not exist
    exit status 1
    

    Note the '\' in that "failed to run" path, vs. the "compiling to" path.

    Environment

    • Mage Version: [run mage --version]
    Mage Build Tool 1.14.0
    Build Date: 2022-09-16T18:08:32Z
    Commit: 300bbc868ba8f2c15b35e09df7e8804753cac00d
    built with: go1.18
    
    • OS: [e.g. windows/linux/mac]
    Windows Server 2019
    10.0.17763.0
    

    Additional context I've worked around it by compiling to a specific output file in the pipeline task, and use that to run targets... Which brings me to a secondary problem- Since the 32bit packages of mage seems to have been dropped, the flows in my pipeline don't work (since there's no windows 32bit package to download). :(

    Would it be possible to add those back into the build? I'd prefer not to compile it myself (I'd have then track mage release changes).

    FWIW, I'm loving mage- thank-you. :)

    :ant: bug 
    opened by johnstoj 0
  • Bug: -d directory  contains magefiles directory does not work

    Bug: -d directory contains magefiles directory does not work

    Bug Description -d directory contains magefiles directory does not work

    What did you do? $ mage -d DIR target

    DIR contains magefiles directory.

    What did you expect to happen? Execute target in DIR/magefiles.

    What actually happened? mage stop with "No .go files marked with the mage build tag in this directory."

    Environment

    • Mage Version: Mage Build Tool v1.14.0 Build Date: 2022-11-04T21:23:44+09:00 Commit: 300bbc8 built with: go1.19.2

    • OS: windows msys2 / linux (WSL2)

    Additional context None

    :ant: bug 
    opened by turutcrane 2
  • Enhancement: Support invocation from a read-only directory

    Enhancement: Support invocation from a read-only directory

    Describe the feature At present, mage can only be run from a writable directory. This means a read-only source tree cannot be used to run even mage tasks which do not by nature attempt to create or modify existing files (think test invocations, or upload operations, or so forth).

    Falling back to a newly-created location under TMPDIR for the executable being compiled -- or allowing an explicit environment variable to be used to specify the location to use -- would avoid outright failure in these scenarios.

    What problem does this feature address? Allows use in environments where read-only trees are preferred for either security (least-privilege: if an operation isn't intended to modify the source it comes from, why let it?) or efficiency (a read-only tree can live in an immutable shared store) reasons.

    Additional context N/A

    :sparkles: enhancement 
    opened by charles-dyfis-net 0
  • Enhancement: Allow to customize mage's Main func

    Enhancement: Allow to customize mage's Main func

    Describe the feature Allowing to customize the mage's main function would be beneficial in some situations. Current, code is half there to allow custom processing in main func. We have public ParseAndRun, Invocation, Command, and Parse functions, but some things are missing. To customize and execute already parsed Invocation, one need to have 2 additional missing bits:

    • function to handle parsing errors
    • function that run Invocation, and Command pair.

    Both of those are currently an internal implementation of ParseAndRun. Splitting this function to separate public functions will allow for such customization.

    What problem does this feature address? Users might want to customize Invocation struct after parsing. For example, I want to contain mage in a build subdirectory, with its own go.mod file. To accomplish that, I like to set the following values on Invocation:

    inv.WorkDir = ".." 
    inv.Dir = "."
    

    Of course, people could like to customize the execution in some other way as well.

    :sparkles: enhancement 
    opened by cardil 0
Releases(v1.14.0)
Owner
Mage
A make/rake replacement for Go
Mage
Modern Make

Modern Make About Mmake is a small program which wraps make to provide additional functionality, such as user-friendly help output, remote includes, a

TJ Holowaychuk 1.6k Dec 27, 2022
Concurrent task runner, developer's routine tasks automation toolkit. Simple modern alternative to GNU Make 🧰

taskctl - concurrent task runner, developer's routine tasks automation toolkit Simple modern alternative to GNU Make. taskctl is concurrent task runne

null 235 Dec 14, 2022
Realize is the #1 Golang Task Runner which enhance your workflow by automating the most common tasks and using the best performing Golang live reloading.

#1 Golang live reload and task runner Content - ⭐️ Top Features - ???? Get started - ?? Config sample - ?? Commands List - ?? Support and Suggestions

Oxequa 4.3k Jan 6, 2023
a build tool for Go, with a focus on cross-compiling, packaging and deployment

goxc NOTE: goxc has long been in maintenance mode. Ever since Go1.5 supported simple cross-compilation, this tool lost much of its value. There are st

Am Laher 1.7k Dec 9, 2022
Tool to check for dependency confusion vulnerabilities in multiple package management systems

Confused A tool for checking for lingering free namespaces for private package names referenced in dependency configuration for Python (pypi) requirem

Visma Product Security 522 Jan 2, 2023
An extremely opinionated TypeScript monorepo tool.

Unirepo is an extremely opinionated TypeScript build tool. Typical monorepo management tools in the Node.js ecosystem provide automation aroun

Brandon Bloom 220 Nov 29, 2022
🚀 gowatch is a command line tool that builds and (re)starts your go project everytime you save a Go or template file.

gowatch 中文文档 gowatch is a command line tool that builds and (re)starts your go project everytime you save a Go or template file. Installation To insta

silenceper 738 Dec 30, 2022
🌍 Earthly is a build automation tool for the container era

?? Earthly is a build automation tool for the container era. It allows you to execute all your builds in containers. This makes them self-contained, repeatable, portable and parallel. You can use Earthly to create Docker images and artifacts (eg binaries, packages, arbitrary files).

Earthly 8.5k Dec 30, 2022
A simple tool to help WoW repack administrators manipulate the repack database(s)

WoW Repack Manipulator This tool makes it easier for an administrator of a WoW Repack (private WoW server, basically) to manipulate the database that

Michael Crilly 2 Feb 7, 2022
A Go port of the Rapid Automatic Keyword Extraction algorithm (RAKE)

A Go implementation of the Rapid Automatic Keyword Extraction (RAKE) algorithm as described in: Rose, S., Engel, D., Cramer, N., & Cowley, W. (2010).

Abdullah Joseph 97 Nov 23, 2022
Your dev tool to manage /etc/hosts like a pro!

hostctl This tool gives you more control over the use of your hosts file. You can have multiple profiles and switch them on/off as you need. Why? It i

Gustavo 834 Jan 2, 2023
An attempt to make a cli for dev.to in Go

Devto a cli for dev.to This is a work in progress so don't a expect a full support for Dev API(beta). Table of contents Devto a cli for dev.to Table o

Gealber Morales 5 Mar 13, 2022
It‘s a cmd-line tool like `make` and `task`, supporting nested args and alias using `cobra`

It‘s a cmd-line tool like `make` and `task`, supporting nested args and alias using `cobra`. It's a makefile alternative and a shell wrapper.

null 2 Oct 18, 2022
Upload content to pastes.dev using netcat

paste-netcat Allows you to upload content to paste (and bytebin) using netcat. Example Start an instance of paste-netcat with Docker > git clone https

lucko 5 May 23, 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.

Felipe Marinho 11 Nov 9, 2022
⚡️ A dev tool for microservice developers to run local applications and/or forward others from/to Kubernetes SSH or TCP

Your new microservice development environment friend. This CLI tool allows you to define a configuration to work with both local applications (Go, Nod

Vincent Composieux 1.3k Jan 4, 2023
A simple command line tool using which you can skip phone number based SMS verification by using a temporary phone number that acts like a proxy.

Fake-SMS A simple command line tool using which you can skip phone number based SMS verification by using a temporary phone number that acts like a pr

Narasimha Prasanna HN 754 Dec 31, 2022
A simple command line tool using which you can skip phone number based SMS verification by using a temporary phone number that acts like a proxy

Fake-SMS A simple command line tool using which you can skip phone number based SMS verification by using a temporary phone number that acts like a pr

Narasimha Prasanna HN 754 Dec 31, 2022
A simple yet customisable program written in go to make hackerman-like terminal effects.

stuntman a simple program written in go to make you look like a hackerman Demo stuntman -binar -width 90 -color cyan stuntman -text -width 90 -vertgap

Solaris 10 Aug 4, 2022
Go bindings for OpenCV1.1 (Dev/Zero Dependencies).

Go语言QQ群: 102319854, 1055927514 凹语言(凹读音“Wa”)(The Wa Programming Language): https://github.com/wa-lang/wa Go bindings for OpenCV1.1 PkgDoc: http://godoc

chai2010 116 Dec 6, 2022