DnsControl VS poetry2nix

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?

Hover's DNS is very simple and bare bones. dnsimple works with dnscontrol so I can manage all my domains programatically

Have you tried dnscontrol.org? It ties into the registrar and DNS providers API's

Was typing on phone and thought that was it. This one https://docs.dnscontrol.org/ explains a bit what it does and heres its github https://github.com/StackExchange/dnscontrol

DNSControl[1] or another similar tool also helps a lot when moving. My DNS records are configured by a small JavaScript file in a git repository, and I can very easily point it at another DNS provider.

[1]: https://dnscontrol.org/

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.