I think Nix, as struggle-full as it was, was the right choice, here, although I don't see the flake.nix file
Struggle is a good way to put it! I feel I hit one of Nix's pain points here: packaging software whose dependencies are largely missing from Nixpkgs. On top of that, it was a Python app, and the state of Python packaging is quite a mess.
I also feel it Nix was the right choice. My journey was rather harsh, but I do believe in its approach.
I'm dealing with an app that is breaking every time I try to upgrade a few-years-old version of Node, a version that is no longer on nixpkgs. Right now I just want something that works; I didn't sufficiently budget for ongoing maintenance as the whole site's behind a login.
So in its own way, Nix and Nixpkgs do serve the purpose of software preservation, as long as you have the full commit history for Nixpkgs.
Preservation doesn't imply maintenance however. It's fair for Nixpkgs to delete packages that are no longer supported, as that's a burden on the limited number of maintainers.
By recreating the package and module in my own Flake, I've taken on responsibility for maintaining it myself, and not adding any work to the Nixpkgs maintainers.
NixOS modules in particular aren't easy to extend, so I ended up copying it entirely. And to be honest, the thought of using an old version of Nixpkgs didn't cross my mind while setting up syncserver. Hopefully it's easier to maintain with poetry2nix now that I've got the package working.