You're welcome to add me as a co-maintainer on this if you submit it to macports/macports-ports:

     {macports.halostatue.ca:austin @halostatue}

This will not be a fun retrospective (the status updates are brutal and clear) -- and I've only been using Coveralls for open source projects for years.

There is a chance — depending on how stubborn the cloud infrastructure provider is (and both Google and AWS can be very stubborn because they don't like admitting that they just might possibly be wrong; I have no experience with Azure but imagine its the same) — that Coveralls will be unable to recover from this because rebuilding the infrastructure from zero on a different provider is going to be hard even if there is 100% IaC and even if there's a solid database backup outside of that provider that's accessible.

I hope they can, because they're a reasonable service and provide a lot of value to open source projects for coverage measurement.

That said, I have seen a number of reliable paths to getting extremely slow responses and eventually 500s from the coveralls servers while trying to look at the coverage details. It has felt like there's been a slow decline in Coveralls server quality because of that. (I've never really reported any of these because (a) I hoped that they were seeing these in their logs, metrics, or notifications and (b) I'm not a paying customer and it's easy for me to `open cover/excoveralls.html` or the equivalent.)

(I have tried the major alternative, codecov.io, in the past, but it's been a long time and I find it disappointing that they appear not to keep their example repos / documentation up to date.)

Disclaimer: I haven't tried this yet.

I would want the equivalent of the trixie-slim Docker image (Debian 13, no documentation). It's ~46 Mb instead of ~4Mb as a Docker image, but gives a reasonably familiar interface.

(This is largely based on some odd experiences with Elixir on Alpine, which is where I am doing most of my work these days.)

> There is no real universal intuition you can build up for programming. There is no point at which you've mastered some degree of fundamentals that you would ever be able to cross language family boundaries trivially.

I don't really agree with you on this, even though I agree with everything else here. Then again, I am an outlier where I've used ~40 programming languages in my career. There are a couple of language families (array languages like APL, exotics like BF) where I cannot read it because I've had no real opportunity to learn them, and there's a significant difference in being able to read a language and use a language (I can read, but not really use Haskell -- although I have shipped a couple of patches to small libraries).

I despair at the number of developers in the profession who understand only one or two programming languages…and badly at that.

(It's worth noting that I wholly disagree with the original post. 24 years ago I chose Ruby over Python because of syntax. Ruby appealed to me, Python didn't — purely on syntax. I never pretended that Python was less capable, only that its syntactic choices drove me away from choosing it as a primary language. I'm comfortable programming in Python now, but still prefer using most other languages to Python … although these days that has more to do with package management.)

It isn't necessarily. A _bad_ video can often be worse than a bad description, because I can read a bad description and reformulate and clarify. This is compounded when the video skips the prerequisite steps that a description often needs to add.

So: TL;DW.