"caddy add-package", "caddy remove-package" could be idempotent

[gedw99]

For idempotency, it would be useful if caddy add-package and caddy remove-package could be idempotent.

caddy remove-package, will return "Error: package is not added" if I do it twice.

caddy add-package, will return "Error: package is already added", if I do it twice.

This idempotency is a nice thing in any architecture, when managing a fleet and building a fleet, because you can just store the package list somewhere and then do add-package without worrying if it was done in the past. Treat them like Cows, not delicate kittens :)

what is the best way to handle this ?

```caddy add-package github.com/x/y```, will return "Warn: package github.com/x/y is already added",

[mholt]

I guess that makes sense. Want to submit a PR?

[gedw99]

Hey @mholt

Can you also comment on #6549, since it's related.

Might have some bearing on this PR. I would like to get this as tight as possible since it is SBOM related.

[mholt]

I think we should just stick to idempotency for now. As mentioned in other issues, build automation with these commands isn't really intended (there are better tools for the job like xcaddy).

[gedw99]

Got it . Thanks @mholt for steering me .

[loren-osborn]

I wanted to confirm my understanding of this issue before I look deeper into it:
My understanding of idempotency is identical behavior, no matter how many times of the operation is performed.
My understanding of the use case, however, is that this is primarily for fleet deployment automation. I believe automated tools for fleet deployment primarily depend on exit codes for error detection, while human users primarily rely on error messages.

To clarify the desired behavior I suspect it would still be useful to display human readable error, messages to human users in a non-idempotent fashion (indicating that no change was made), while the exit code should behave idempotently. (Indicating no error deleting something already missing, or adding something already present.)

Is this the desired behavior?

[francislavoie]

Correct @loren-osborn, see #6577 (comment)

[loren-osborn]

Looks like I should spend my time on other tasks if you already have a PR for this issue.

[gedw99]

agree that error codes are a key element automation.