PSA: On the surface it looks great - but it's something that spawns a Python server (with uv - I think) and does communicate with it during tests. I don't think it's complexity we need to take on on our unit tests.
A saner approach would be to start with a FFI-friendly language and create bindings. I don't think just being able to use an already written framework in Python is worth the trade-off.
Trying to make my Rust library `composable-indexes` more ergonomic. It is for indexing a collection on multiple dimensions in a type-safe and composable manner.
In other words, something safer & more concise than maintaining multiple HashMap's, but a lot less involved & simpler than an in-memory SQLite.
You are right, the best region that optimises median latency against all internet users over the world is `us-west-3`, which is Paris - I believe. Likely because it has much better latency towards Asia where the majority of internet users are.
I also investigated which two regions to choose for a multi-region setup, which ends up being London and Japan.
Turkish here. It's hard to believe, but there are different kinds of ice cream in Turkey.
The average ice-cream ("dondurma" in Turkish) you'd get in Turkey is the one you expect: sorbet or gelato, usually in a cone. It's what you'd get when you ask for an ice-cream at a random place.
The one described in this post is a specific kind of ice-cream we call "ice-cream from Maraş" ("Maraş dondurması" in Turkish). Which is great - but the post makes it sound like it is "the Turkish ice-cream" which is a bit misleading. You don't find it everywhere.
You're right! All layers except the topmost layer consist of non-overlapping store paths. It's not one-path-per-layer as there's a hard limit on number of layers, so we smush the packages "deeper" in the dependency tree together within a single layer. There was some work recently where you could specify which paths should correspond to which layers but I can't recall the exact function.
You do have the ability to add a "customisation" layer on top of your image in case you want to create some directories or run arbitrary modifications which does end up as an extra layer which _can_ override the previous layers hence it's always the topmost. But you usually don't need it.
Source: I did a large-ish refactor to the `buildLayeredImage` functions a couple of years ago. My contribution was adding a `streamLayeredImage` function where you can "stream" a derivation to a Docker image on-the-fly without copying any files/layers in the disk.
Hey, author of the library here, thanks for your comment! Disclaimer: It's been more than a year since I've written this, so I might've forgotten things.
This actually teaches me that one thing I should make it clear is this was essentially a weekend experiment from someone who has never used, let alone written a Lisp before.
There's no way it's a production grade software, there are places where the evaluator just borks for valid expressions.
I learned a lot when writing it, so I can probably do a large-ish refactor that would simplify many things and fix the inconsistencies.
> this uses lazy evaluation, because most Lisps use strict evaluation.
The evaluation semantics are pretty weird. It's lazy-ish mostly, but when evaluating there are a lot of places where I unnecessarily force evaluation of things. So I should make the semantics clearer and document them.
> The behaviour of the top-level forms changes when they are wrapped in `begin`
This is a bug, you are right .
> Since this dialect is pure (no side effects)
It's mostly pure. There are a couple of constructs like `assert` and `log` that perform side effects. And also as you mentioned the expressions in a begin can be macros that end up modifying the environment.
> The way `if` handles values other than true/false is backwards compared to most Lisps
You are likely correct and this is a bug!
---
Thanks again of your comments, I'll try to find some time to either rewrite the project, or at least document it better.
A saner approach would be to start with a FFI-friendly language and create bindings. I don't think just being able to use an already written framework in Python is worth the trade-off.