DnsControl VS poetry2nix

I'm excited to share a comprehensive example repository that demonstrates the complete workflow from DNSControl JavaScript configurations to a production-ready containerized DNS server:

DNSControl is how you get there. It is an open-source tool from Stack Exchange that treats your DNS zone as code. You define records in a config file, run a preview to see what would change, and push to apply. It supports Cloudflare, Route53, and about 30 other providers.

I've tested just about every DNS provider I could find. Self-hosting aside, I always come back to CloudDNS and LuaDNS. I'm currently using LuaDNS as a "dumb" DNS host (i.e., not using their Lua configuration-as-code system), managed using DNSControl.

https://www.cloudns.net/premium/

https://www.luadns.com/pricing.html

https://dnscontrol.org

I've found every other offering to be lacking. Some examples: Cloudflare is alright but has settings footguns if you're not used to Their Way of Doing It™. deSEC is free but sometimes quite slow to propagate, and its UI and API are unwieldy. DNS Made Easy is often advocated for on social media, but it seems ridiculously expensive so I've never even trialed it.

I compared OctoDNS with DNSControl (https://github.com/StackExchange/dnscontrol) a few years ago and settled with DNSControl because it had more providers out of the box.

But using either of these tools to have your DNS redeploy-able to a new provider is a great idea for resiliency.

See RFC5507: "Why Adding a New Resource Record Type Is the Preferred Solution"

DNS providers should support a wide range of RR types, and domain owners should vote with their NS records.

See https://github.com/StackExchange/dnscontrol/blob/master/docu... for a list of DNS providers that support CAA.

I would create an AWS account for Route53 only. No other services or resources would be deployed. To manage the DNS records I may use: https://github.com/StackExchange/dnscontrol

How is this compared to https://dnscontrol.org/ from Stackoverflow?

When I say that Nix does not automatically pick up the dependencies from the pyproject.toml file, I am not telling the whole truth. Tools like poetry2nix and some community functions can help you with this, but I do not want to rely on them. I want a vanilla solution.

I think it's also an issue with the flexibility paradox. There isn't a good single way to package Python for Nix because before you even start there are several key questions which come up that most other distros can't even begin reasoning about:

- Are we packaging just one Python package for Nix, or a thing and all its dependencies?

- Is the package already on PyPI, and are we packaging the source from there, or is it the source from some upstream?

- Are any of the dependencies coming from source, either their upstreams or forks?

- For dependencies that already exist in the nixpkgs SHA that is supplying the Python interpreter, do we want to use those versions, or package newer versions? Is it the same decision for everything, or does it vary?

- Is there already a Python level dependency locking scheme in place such as poetry/pipenv/uv, or is it a plain setuptools package? Is it acceptable for Nix to become the locking mechanism, or will that mess things up for non-Nix consumers of this?

- Are we looking to supply a development environment here too, or is this purely about deployment?

To be clear, none of this is an excuse— it's horrifying that there can't be a single "Tool X is the singular Python-on-Nix story, follow the one page tutorial and you're all set". But I think the massive amount of choice and flexibility is the crux of why new methods and tools are still being rapidly invented and proposed.

For myself, I would choose poetry2nix as how I'd ship a Python project to Nix hosts, but that immediately implies some answers to a bunch of the above questions, mandates poetry for your top level project, and once you look closer there turn out to be some truly horrifying implementation details [1] that are what make poetry2nix appear as seamless and friendly as it does.

[1]: https://github.com/nix-community/poetry2nix/blob/master/over...

So let’s get straight to the meat. The following Flake dives you a development shell that tries to replicate the underlying poetry project in full nix using poetry2nix.

How about converting it to Nix derivation?

https://github.com/nix-community/poetry2nix

This looks really strange because I do not know how to solve it and also because it looks like the sha256 that I am setting is not the one that Nix will match. I read also https://github.com/nix-community/poetry2nix/issues/413 but I was not able to solve the problem.

There's a project that does this with using Nix: https://github.com/takeda/nix-cde (this is a wrapper around https://github.com/nix-community/poetry2nix)

{ description = "Application packaged using poetry2nix"; inputs.flake-utils.url = "github:numtide/flake-utils"; inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; inputs.poetry2nix = { url = "github:nix-community/poetry2nix"; inputs.nixpkgs.follows = "nixpkgs"; }; outputs = { self, nixpkgs, flake-utils, poetry2nix }: flake-utils.lib.eachDefaultSystem (system: let # see https://github.com/nix-community/poetry2nix/tree/master#api for more functions and examples. inherit (poetry2nix.legacyPackages.${system}) mkPoetryEnv; pkgs = import nixpkgs {inherit system;}; python = pkgs.python310; pythonEnv = mkPoetryEnv { inherit python; projectDir = ./.; preferWheels = true; }; in { #packages.default = mkPoetryEnv { # projectDir = ./.; # python = pkgs.python310; #}; devShells.default = pkgs.mkShell { buildInputs = [pythonEnv]; packages = [ poetry2nix.packages.${system}.poetry pkgs.cairo pkgs.pkg-config pkgs.gobject-introspection pkgs.tk ]; }; }); }

A cleaner way might be to use https://github.com/nix-community/poetry2nix which can load poetry.lock inside Nix. I still need to try it for torch, but it does seem like a clean way to use it.

The README for poetry2nix (https://github.com/nix-community/poetry2nix) seems to indicate that all extras should be enabled by default.