- https://codeberg.org/kiara
- Joined on
2025-02-04
this draft PR so far seems not to address how to associate such versions with deployment modules revisions, which could be covered by a custom mapping. that seems relevant in case we update things after an operator deploys (#159), but also in case of migration across different versions (Fediversity/Fediversity#100 (comment)).
for my understanding, are we using getattr so the type checkers won't cry?
separate versions as code impose extra burden on PR reviewers, as it will not by default show diffs when going from a v1 to v2. for that purpose it would seem more elegant to store generated variants by version (whether in source or a db, stored in full or by revsets), such that the source can stay diff-friendly.
django control over schemas may make it harder to verify such a schema works out with the property translations the nix back-end would then need to write.
if django is to be in control of the schema, how would we verify schema compatibility between django and our deployment module?
maybe defer making this dynamic (by e.g. username like here) until we get a DNS provider to ensure we can reflect this?
without DNS provider probably even two options is more than we can do
as things grow and we would get closer to exposing e.g. nix module options, this manual approach seems to scale less well, compared to generating this from upstream schemas (or potentially our own derivatives).
having to do this feels a bit dirty 🥲 but maybe that seems part of the other discussion
^ i guess it works, but fwiw it feels hacky, even without the module getting loaded every time