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.
I'm sorry in advance for perpetuating the flamewar.
Disclaimer: Turkish here. I do not deny the Armenian Genocide, or think it was right for Azerbaijan to reclaim Karabakh with this way.
You are falling to the same fallacy as the Turkish government:
* Claiming Khojali massacre is a lie, disregarding the documented facts. Do not bring yourself down to the same level as genocide deniers; they will beat you with experience.
* The "they did that too" argument; as if any horrible act legitimizes the other one.
So, it makes a much better discussion if we all agree on documented facts and try to move forward from there (if there is any solution to move forward to). The "Armenian Genocide didn't happen" versus "Khojali Massacre didn't happen" discussion seems childish at this point, and it is not going to help either side in the long run.
As someone who is using NixOS for 8+ years, I do agree with both your problems.
(1) I do find that it's very rare having to implement a low level transitive dependency from scratch (most low-level system dependencies are already there, and for dependencies of a specific programming-language ecosystem you'd usually auto-generate them from things like `yarn2nix` or `poetry2nix`). However, I agree that once you need to do that for non-trivial library it quickly becomes painful and require intimate knowledge of both the build system and Nix environment.
(2) This is my main issue. My workflow is also having a local `nixpkgs` clone, and go find the function and the parameters I can use every time I don't remember how to use it. I also think that it is sustainable. There are many exciting improvements going on with the new CLI, so hopefully we will get nicer error messages and better tooling support in near future.
> but the execution has been a miserable experience for me to the extent that I can't make sense of people who report such positive experiences.
There are pain points, but the advantages for me were indispensable. Being able to pin dependencies accurately, reproduce an exact development environment deterministically, and use the single language to define applications, configurations, and even entire system images is a great benefit that I would need to use 10+ tools with individual quirks otherwise.
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.