dew
bazel_compose
| dew | bazel_compose | |
|---|---|---|
| 3 | 1 | |
| 7 | 12 | |
| - | - | |
| 5.5 | 0.0 | |
| about 1 month ago | over 3 years ago | |
| Shell | Python | |
| - | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dew
-
RHttp: REPL for HTTP
I've built dew for this. It "knows" about many of those apps (and where to get a container from). https://github.com/efrecon/dew. Adding a term app is usually just a matter of crafting an .env file with the necessary settings.
-
Toolship: A (More) Secure Workstation
I have written dew (https://github.com/efrecon/dew) for more or less the same purpose. I hardly keep any binary (and dependency) in my installation, they are all inside containers that I can easily dispose of at any time. The default in dew is to run them as your user. At the command prompt, instead of running, for example, kubectl xxx, I run dew kubectl xxx. It's a bit slower but provides an increased level of security.
-
You Don't Need to Rebuild Your Development Docker Image on Every Code Change
In the past few weeks, I have spent some time and released dew [0]. It helps encapsulating this kind of setups in configuration and minimising typing. dew is still evolving, but it has served me well.
[0]: https://github.com/efrecon/dew
bazel_compose
-
You Don't Need to Rebuild Your Development Docker Image on Every Code Change
While this is great for people with a fundamental understanding of containers and your prod environment this will usually lead to some issues with developers that don't need to, or want to, have context in these areas.
In the past, to make a very similar workflow possible, I've built tools that automatically watch your source files and rebuild & restart only what is needed [0]. This was built for bazel + docker-compose but there isn't a reason one couldn't watch the "build:" contexts for what files are important.
At a previous company one of our engineers was a huge fan of this volume mount approach and every single time something broke (which was very frequent due to some prod/dev env magic we had) I had to assist quite a few more junior devs figure out what was wrong with their machine. For those with scripting languages, was it their system's newline endings? For compiled languages, was their system SDK different then what was in the container? For prod bugs, did they forget to rebuild & test the container before opening their PR (we had no automated integration testing)?
In my opinion, if you can make your build system in charge of building/packaging things you'll have a much happier time.
[0] - https://github.com/CaperAi/bazel_compose
What are some alternatives?
toolship - A framework to containerize dev tools
Docker Compose - Define and run multi-container applications with Docker
skaffold - Easy and Repeatable Kubernetes Development
telepresence - Local development against a remote Kubernetes or OpenShift cluster
volta - Volta: JS Toolchains as Code. ⚡