Docker makes a distinction between container creation and container start, so an option called enableOnBoot is ambiguous. I'd go with startOnBoot.

Docker natively supports starting containers on boot via restart=always. The fact that this PR does it differently should be documented in the option description.
I do think it's a good choice to avoid exposing docker's restart policies. It seems better to split it into more options, e.g. startOnBoot, startOnExit, startOnFailure (no effect if startOnExit is true).

So I think startOnBoot is a more consistent name.

EDIT: the other options I named don't have to be included in this PR necessarily.

docker-containers doesn't use the dockerd to start the containers on boot, it uses systemd services. Using Docker's terminology for it would be a bit confusing.
Same goes for restart policies, those are systemd's too (see #76479).

I think @danbst's suggestion is what we should go with, it's unambiguous and matches what nixos-containers use.

Using Docker's terminology for it [docker-containers] would be a bit confusing.

Interesting.

it uses systemd services.
Same goes for restart policies, those are systemd's too

Sure, but should a user of this module care about these implementation details?

it's unambiguous

No it's not. The OnBoot suffix indicates that what precedes it is an operation to be performed at system boot time. However, "enable" is not a defined operation on docker containers.

"Enable" is used in NixOS (a lot) to define things into existence (or inhibit their existence).

Suppose I have a container for a service that I only run when a certain event happens. Certainly this container has to be "enabled": I want it to be downloaded, held onto by the system and to be ready to run. However, it should not be started on boot, because it's designed to be triggered by my event.

startOnBoot or autoStart are both good names IMO. "enable" word is quite overused already.

Using Docker's terminology for it [docker-containers] would be a bit confusing.

Interesting.

Don't quote me out of context like that, the sentence only makes sense together with the one preceding it.

it uses systemd services.
Same goes for restart policies, those are systemd's too

Sure, but should a user of this module care about these implementation details?

If it directly affects how their configuration option makes their system behave, yes.

It should be documented however.

it's unambiguous

No it's not. The OnBoot suffix indicates that what precedes it is an operation to be performed at system boot time. However, "enable" is not a defined operation on docker containers.

"Enable" is used in NixOS (a lot) to define things into existence (or inhibit their existence).

@danbst's suggestion contains none of those words.

Suppose I have a container for a service that I only run when a certain event happens. Certainly this container has to be "enabled": I want it to be downloaded, held onto by the system and to be ready to run. However, it should not be started on boot, because it's designed to be triggered by my event.

A container being available to the system is implied when you declare it in your system configuration.

Don't quote me out of context like that,

I didn't mean to offend you and that was needlessly polarizing. We're on the same team :) (team Nix)

I'm trying to help you with naming, as you've indicated that it needed attention.

A container being available to the system is implied when you declare it in your system configuration.

Yes, always creating the container is a good idea (or good default*). What should be configurable is after which events to start it.

(* An enable option to inhibit even the creation, analogous to https://nixos.org/nixos/options.html#systemd.services.%3Cname%3E.enable might make sense, but that's speculative at this point.)

I didn't mean to offend you and that was needlessly polarizing. We're on the same team :) (team Nix)

I'm not offended, no worries.
I was arguing against an argumentation/comment that I thought was poor because it tried to argue against an argument taken out of context and thereby robbed of its sense.
Whose argument it was against and who made it don't matter to me.

I'm trying to help you with naming, as you've indicated that it needed attention.

You're more than welcome to do and continue doing that as far as I'm concerned.

Yes, always creating the container is a good idea (or good default*). What should be configurable is after which events to start it.

That's exactly right and made me think of a good point just now: This PR's option is only binary.
Maybe it'd be better to make the whole WantedBy configurable with [ multi-user.target ] as the default.

(* An enable option to inhibit even the creation, analogous to https://nixos.org/nixos/options.html#systemd.services.%3Cname%3E.enable might make sense, but that's speculative at this point.)

Might be a good idea to open a separate issue/PR for that option.

@Atemu thanks, finally got hands to test this, works fine