As Repl.it has become more powerful we've used it to build and host many of our internal tools and parts of the site itself. This gives us a great opportunity to eat our own dog food and in the process make Repl.it better.
Most recently we moved our blog (the one you're reading right now) into a repl! Notice the "edit on Repl.it" in the upper right corner? That takes you straight to the markdown file for this particular blog post. The same repl is also embedded below, you can explore it right here, even fork and play around with it.
But this isn't the only page build in a repl. When creating any new feature we try to first prototype on Repl.it and, if possible, host it there forever. Pages like our docs, jobs, and even the repl.run product are all hosted entirely in a repl. We've found repls lend themselves especially well to light self contained services. Many of our internal tools and some parts of the site work very well with the repl model.
We've found tracking pull requests across many repositories on Github has a lot of overhead. It isn't always clear what to review. Checking many repositories is time consuming and trying to use Github's notifications is a bit of a mess. To solve this we created Boops. The concept is very simple: any PR with the label
boop will be listed on a shared board everyone can see. If you want your PR reviewd you add the
boop label. This alone might not be very useful but it becomes much more powerful when anyone can create repls to manipulate labels as they see fit. One repl "The Unbooper" goes around removing
boops from any PRs with failing tests or unaddressed feedback. Another repl will automatically add
boop to a PR with the label
preboop if it passes the checks. There is of course a
superboop label you can add when you want to ward off the unbooper.
All together this creates a board with very high signal on PRs requiring human attention. Here's what our boop board looks like right now:
Repl.run turns any terminal app into a website you can share. To build this we leaned heavily on our existing infrastructure. The page is actually hosted statically from a repl and starts up a fresh container using our api.
install all of pypi
repl forks and runs another repl for every deploy
- python packge resolver
install every package on pypi to figure out what it provides