All Projects → twitchtv → Retool

twitchtv / Retool

Licence: apache-2.0
Vendoring for executables written in Go

Programming Languages

go
31211 projects - #10 most used programming language

Projects that are alternatives of or similar to Retool

Apollo Tooling
✏️ Tooling for development and production Apollo workflows
Stars: ✭ 2,938 (+629.03%)
Mutual labels:  code-generation
Regenerate
Generate JavaScript-compatible regular expressions based on a given set of Unicode symbols or code points.
Stars: ✭ 306 (-24.07%)
Mutual labels:  code-generation
Llvm Hs
Haskell bindings for LLVM
Stars: ✭ 370 (-8.19%)
Mutual labels:  code-generation
Pacote
programmatic npm package and metadata downloader (moved!)
Stars: ✭ 281 (-30.27%)
Mutual labels:  package-management
Easyjson
Fast JSON serializer for golang.
Stars: ✭ 3,512 (+771.46%)
Mutual labels:  code-generation
Webrpc
webrpc is a schema-driven approach to writing backend services for modern Web apps and networks
Stars: ✭ 342 (-15.14%)
Mutual labels:  code-generation
Graphit
GraphIt - A High-Performance Domain Specific Language for Graph Analytics
Stars: ✭ 254 (-36.97%)
Mutual labels:  code-generation
Awesome Roslyn
Curated list of awesome Roslyn books, tutorials, open-source projects, analyzers, code fixes, refactorings, and source generators
Stars: ✭ 395 (-1.99%)
Mutual labels:  code-generation
Modulation
Modulation - explicit dependency management for Ruby
Stars: ✭ 306 (-24.07%)
Mutual labels:  package-management
Javaparser
Java 1-15 Parser and Abstract Syntax Tree for Java, including preview features to Java 13
Stars: ✭ 3,972 (+885.61%)
Mutual labels:  code-generation
Fpp
Functional PHP Preprocessor - Generate Immutable Data Types
Stars: ✭ 282 (-30.02%)
Mutual labels:  code-generation
Data desk
New version "Metadesk" at https://github.com/Dion-Systems/metadesk
Stars: ✭ 289 (-28.29%)
Mutual labels:  code-generation
Go Sword
【Go-sword】可视化CRUD管理后台生成工具
Stars: ✭ 364 (-9.68%)
Mutual labels:  code-generation
Xmlschemaclassgenerator
Generate C# classes from XML Schema files
Stars: ✭ 277 (-31.27%)
Mutual labels:  code-generation
Mini C
Dr Strangehack, or: how to write a self-hosting C compiler in 10 hours
Stars: ✭ 372 (-7.69%)
Mutual labels:  code-generation
Efdesigner
Entity Framework visual design surface and code-first code generation for EF6, Core and beyond
Stars: ✭ 256 (-36.48%)
Mutual labels:  code-generation
Conan Center Index
Recipes for the ConanCenter repository
Stars: ✭ 310 (-23.08%)
Mutual labels:  package-management
Kroto Plus
gRPC Kotlin Coroutines, Protobuf DSL, Scripting for Protoc
Stars: ✭ 400 (-0.74%)
Mutual labels:  code-generation
Swaggen
OpenAPI/Swagger 3.0 Parser and Swift code generator
Stars: ✭ 385 (-4.47%)
Mutual labels:  code-generation
Loopy
A code generator for array-based code on CPUs and GPUs
Stars: ✭ 367 (-8.93%)
Mutual labels:  code-generation

Retool: Vendor thy tools!

Build Status Windows Build status

what is this

retool helps manage the versions of tools that you use with your repository. These are executables that are a crucial part of your development environment, but aren't imported by any of your code, so they don't get scooped up by glide or godep (or any other vendoring tool).

Some examples of tools:

You want this if you use code generation: if everybody has a different version of the code generator, then you'll get meaningless churn across runs of the generator unless everyone is pinned to the right version.

You might also want this if you use linters or tools like github.com/kisielk/errcheck in an automated fashion and you want to make sure that everyone has the same version so you can pass flags to the linter with confidence.

retool pins on a per-project basis. It works by making a complete GOPATH within your project. You can choose to commit the source files for those tools, if you like.

usage

The expected workflow is something like this:

Install retool:

go get github.com/twitchtv/retool

Add a tool dependency:

retool add github.com/jteeuwen/go-bindata/go-bindata origin/master

Use it to generate code:

retool do go-bindata -pkg testdata -o ./testdata/testdata.go ./testdata/data.json

There are a few other commands that you'll use much less often:

Upgrade a tool to its latest version:

retool upgrade github.com/spf13/hugo origin/master
# or to a particular tag
retool upgrade github.com/spf13/hugo v0.17

Stop using that tool you dont like anymore:

retool remove github.com/tools/godep

Compile all the tools that other people have vendored in a project:

# compiles everything without using the network - useful for isolated build environments
retool build

Double-check that you're in sync by comparing everything with upstream versions:

# makes sure your tools match tools.json by comparing against their remotes
retool sync

why would i need to manage these things

TL;DR: if you work with anyone else on your project, and they have different versions of their tools, everything turns to shit.

One of the best parts about Go is that it is very, very simple. This makes it straightforward to write code generation utilities. You don't need to generate code for every project, but in large ones, code generation can help you be much more productive.

Like, if you're writing tests that use an interface, you can use code generation to quickly whip up structs which mock the interface so you can force them to return errors. This way, you can test edge cases for your interaction points with interfaces. github.com/maxbrunsfeld/counterfeiter does this pretty well!

If you want to use the generated code, you should check in the generated .go code to git, not just the sources, so that build boxes and the like don't need all these code generation tools, and so that go get just works cleanly.

This poses a problem, though, as soon as you start working with other people on your project: if you have different versions of your code generation tools, which generate slightly different output, you'll get lots of meaningless churn in your commits. This sucks! There has to be a better way!

the retool way

retool records the versions of tools you want in a file, tools.json. The file looks like this:

{
  "Tools": [
    {
      "Repository": "github.com/golang/protobuf/protoc-gen-go",
      "Commit": "2fea9e168bab814ca0c6e292a6be164f624fc6ca"
    }
  ]
}

Tools are identified by repo and commit. Each tool in tools.json will be installed to _tools, which is a private GOPATH just dedicated to keeping track of these tools.

In practice, you don't need to know much about tools.json. You check it in to git so that everybody stays in sync, but you manage it with retool add|upgrade|remove.

When it's time to generate code, instead of go generate ./..., you use retool do go generate ./... to use your sweet, vendored tools. This really just calls PATH=$PWD/_tools/bin:PATH go generate ./...; if you want to do anything fancy, you can feel free to use that path too.

contributing to retool

Any pull requests are extremely welcome! If you run into problems or have questions, please raise a github issue!

Retool's tests are mostly integration tests. They require a working Go compiler, a working version of git, and network access.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].