I have started using this immediately as I saw the release tweet - solves a real problem for me whenever I am working on a project that doesn't use Docker. Good stuff!
Thanks! That's great to hear!
Spin up your development background processes with ease
21–30 of 30 posts
Re: Spin up your development background processes with ease
#22I've done something similar with Nix and supervisord before. On the one hand, I think this kind of simplified config format can be nice for teams who don't want to have to contend with the process supervisor in all its complexity. On the other, supervisord is pretty simple already.
Good point, I think there are many approaches to solving this problem, and every approach having pros and cons. I'm adding some additional features like auto restart when files are modified but overall I agree that this simplified config format can be nice for teams who don't want to have to contend with the process supervisor in all its complexity.
Re: Spin up your development background processes with ease
#23I'm excited for this tool. I don't use Docker so something like this is going to make my life much easier. I like the idea of being able to hop between projects and start all the processes I need for that project with one command.
Thanks Aaron! That's great to hear!
Re: Spin up your development background processes with ease
#24the only advantage over docker that I see is that it doesnt require the overlay fs stuff docker has, but the downside of this is that it doesnt keep its own state. It seems to use system state, such as any global configuration, caches, etc. I prefer docker compose, simply because its fully reproducible, no matter where I am, and sets up all the tools it uses. This tools looks like it still requires you to install you…
Agree, it all depends on your use case. Docker is amazing for projects that require services that are difficult to install, configure and maintain on your main OS.
Porter is ideal for those already running these services on their main OS and just need something to run and manage these services more easily.
Re: Spin up your development background processes with ease
#25amazing, I only wish for the VS Code integration
Thanks! You can use the build-in terminal VS Code provides to run any of the Porter commands. What would you like to see in a native VS Code extension?
I was looking for an extension to do the following: when I open a project (and maybe press a status bar button), it runs all the processes I need (from the config in the root of the project) and streams their logs in separate terminals (so I can see those logs immediately); when I close the projects, all of this gets shutdown
Re: Spin up your development background processes with ease
#26What's the advantage of using this over systemd user services? https://wiki.archlinux.org/title/Systemd/User Again, services are configured with short text-based configuration files.
Good question, I think there are many different approach on solving running multiple services. So it boils down to what you need, and what works for you. One advantage might be the ease of use. Using Porter you don't need to know anything about Supervisor, systemd or other more technical implementations. Porter abstracts away these things so you only have to write a simple .yml file.
> Using Porter you don't need to know anything about Supervisor, systemd [...]
Using systemd you don't need to know anything about Porter.
> One advantage might be the ease of use. [...] Porter abstracts away these things so you only have to write a simple .yml file.
Is the systemd unit file really that much more complex? The example `mpd` service file might take more lines than the equivalent Porter .yml snippet, but the DOS/Windows 3-era ".ini" file format isn't exactly rocket surgery, and there's only one kinda weird bit of boilerplate ("WantedBy=default.target") that isn't immediately obvious why it's there. Other than that, the systemd config for a simple service is, well, simple. (At least, it looks that way to me.)
https://wiki.archlinux.org/title/Systemd/User#Example
Yeah, there's a lot of complexity you can add with systemd units, but only if you have complex use-cases that need it. As far as I can tell, the only alternative to "Yeah, there's a config option for that, but it can take a bit of reading to find out its name" is "No, you can't do that, sorry".
As Alan Kay's classic adage goes, "simple things should be simple, complex things should be possible" :-)
Re: Spin up your development background processes with ease
#27This is cool. I've been looking for something like this to pair with my nix env. Docker makes process management and logging in the dev environment so easy, but between the performance issues and abstraction leaks when jumping back and forth between native containers on linux and virtual machines on macos we gave up and started using nix to handle the reproducibility of our dev environment. The only thing I miss is t…
https://evilmartians.com/chronicles/introducing-overmind-and...
Devenv.sh is using these (out of the box)
Re: Spin up your development background processes with ease
#28Really cool, love the idea of managing background services for your dev environment, without having to use Docker Compose.
We’ve been working on a similar workflow with Devbox (https://jetpack.io/devbox), using Nix to install and run dev env services
Re: Spin up your development background processes with ease
#29Am I the only one who uses a development Nomad cluster to solve the exact same problem? Not sure what this and other tools suggested in the comments here have over Nomad.
Nomad can schedule anything: random JAR files, scripts, Docker/Podman containers, firecracker VMs, you name it.
Re: Spin up your development background processes with ease
#30This is cool. I've been looking for something like this to pair with my nix env. Docker makes process management and logging in the dev environment so easy, but between the performance issues and abstraction leaks when jumping back and forth between native containers on linux and virtual machines on macos we gave up and started using nix to handle the reproducibility of our dev environment. The only thing I miss is t…
https://evilmartians.com/chronicles/introducing-overmind-and... Devenv.sh is using these (out of the box)
Btw, there's a large number of tools that use the Procfile file format, including what appears to be the original one, written in Ruby https://github.com/ddollar/foreman (the readme has links to a partial list of foreman clones)
But I agree that overmind is the best of the bunch