A note: In my limited testing with lpadmin, if you add an existing printer again, any printer settings you have changed (for the given printer) seem to be reset. (so for example if reconfiguration calls lpadmin again)

Not a breaking thing, but possibly a bit annoying.
What is the behavior of "oneshot"?

When I poked at /etc/cups/printers.conf , printers had UUIDs. Its also possible the entry it just being overwritten with a new UUID so it only looked like the same entry, I haven't checked.

if you add an existing printer again, any printer settings you have changed (for the given printer) seem to be reset. (so for example if reconfiguration calls lpadmin again)

@deliciouslytyped that's actually my intention here, as the alternative would be that what's written in the nix config and the actual state of the printer can easily diverge, which I wanted to avoid as far as possible. I tried to improve the documentation in that this isn't a one-time thing, but will actually happen on each reboot or restart of cups. "oneshot" means that the lpadmin commands are run like a script on startup of cups. The main identifier is the printer name here; so subsequent lpadmin calls from the service will modify the existing printer.

Found the cups tests, rewriting them to use this instead of manual lpadmin commands…

Hm. Ok, I guess that's a reasonable decision, but I still feel some cognitive dissonance given that the stuff is basically mutable and on a first look doesn't appear touch any of the values in question.
TL;DR: I don't know what to do/think about it, just a little uneasy.

and on a first look doesn't appear touch any of the values in question

@deliciouslytyped Not sure what you're refering to here, could you explain what do you mean by that?

@GrahamcOfBorg test printing

Added support for socket activation, and added a socket activation version to the printing test to catch such errors.

@Mic92 replaced all but one sleep with waitUntilSuceeds (no sure what I could match on to find out that service-based cups is actually ready and accepts printing jobs), and also find out about $machine->name() with which I could replace the my name = $machine->succeeds('hostname'); chomp $name; calls inside the testing function.

@GrahamcOfBorg test printing

Damn, time for 19.09 already… But rebased, resolved conflicts, adressed more change requests. :)

@etu Thanks for your offer! 👍 In addition to doing another round of proofreading and testing with the new changes (and old ones like the waitUntilSucceeds changes which vanished somehow but are now recreated),
could you please take a look at my expanded description for #55510 (comment) , and try to reproduce #55510 (comment) ?
Also, if you know Perl better than I do, could you try to get rid of that Machine::retry thing I don't understand like suggested here? That would help alot, thank you!

Conflicts in the printing test is 01cd466, where it's default socket activated now.

In light of #53027, would we want to have paper size as a declarative option?

In light of #53027, would we want to have paper size as a declarative option?

That could be a very nice thing, at least for us that aren't in the US.

But at the moment I'm more worried if we get it in at all before the release.

Freeze in 10 days. https://discourse.nixos.org/t/nixos-19-09-feature-freeze/3707

Just resolved the conflicts, continuing to have both always-running and socket-activated cups in the tests because why not when I already wrote the code for both. But I don't cling to that.

@aaronjanse @etu thank you for reminding me, I already had the code to specify arbitrary ppd options laying around but forgot it was not yet included in this PR. Added those options, handy for working drivers with duplex print and the like, though they obviously don't help against broken drivers like in #53027.

Calling in @matthewbauer (:+1: for making socket activation the new default) as new cups module maintainer for decision on what to do with this.

@GrahamcOfBorg test printing

@etu @worldofpeace thanks! :)

To anybody lurking here and wanting to try this out, you can use this snippet here on stable 19.03 and then start to configure your printers declaratively right now:

{ ... }:
let
  declarativePrintersNixpkgsFJ = builtins.fetchGit {
    name = "florianjacob-nixpkgs-declarative-printers";
    url = https://github.com/florianjacob/nixpkgs/;
    ref = "declarative-printers";
    rev = "18a5d23b55d0b0d1bff6bfd971d471d3064011c2";
  };
in {
  imports = [
    "${declarativePrintersNixpkgsFJ}/nixos/modules/hardware/printers.nix"
  ];
}

If nobody comes with any real complaints about this before Friday (2019-09-06), I intend to merge it by then because it works perfectly fine in my tests.

cc @disassembler @infinisil @Mic92

Looking good, let's go :)