borgmatic-collective/borgmatic
borgmatic-collective/borgmatic
10
66
Fork 30
Code Issues 45 Pull Requests 5 Actions Packages Releases 145 Activity

Move external borgmatic config commands into borgmatic #529

New Issue
Closed
opened 2022-05-07 11:05:50 +00:00 by andibm · 13 comments
andibm commented 2022-05-07 11:05:50 +00:00
Copy Link

Hi, it would be great if all borgmatic related commands could start with "borgmatic":

generate-borgmatic-config → borgmatic-generate-config
upgrade-borgmatic-config → borgmatic-upgrade-config
validate-borgmatic-config → borgmatic-validate-config

This would simplify finding them using shell-completion when you don't remember them exactly without looking up the documentation. Of course a minor wishlist suggestion.

Best Regards, Andi

Hi, it would be great if all borgmatic related commands could start with "borgmatic": generate-borgmatic-config → borgmatic-generate-config upgrade-borgmatic-config → borgmatic-upgrade-config validate-borgmatic-config → borgmatic-validate-config This would simplify finding them using shell-completion when you don't remember them exactly without looking up the documentation. Of course a minor wishlist suggestion. Best Regards, Andi
👍 2
witten commented 2022-05-07 16:26:31 +00:00
Owner
Copy Link

Thanks for this suggestion! I like the idea of improved discoverability. What do you think about integrating these commands into the main borgmatic executable instead? That way they'd show in --help, etc.

Examples:

  • generate-borgmatic-config → borgmatic generate
  • upgrade-borgmatic-config → borgmatic upgrade
  • validate-borgmatic-config → borgmatic validate
Thanks for this suggestion! I like the idea of improved discoverability. What do you think about integrating these commands into the main `borgmatic` executable instead? That way they'd show in `--help`, etc. Examples: * `generate-borgmatic-config` → `borgmatic generate` * `upgrade-borgmatic-config` → `borgmatic upgrade` * `validate-borgmatic-config` → `borgmatic validate`
andibm commented 2022-05-07 18:21:51 +00:00
Author
Copy Link

Yes, probably slightly more work, but even better, I guess. The only issue I see from an end-user perspective is the confusion related to something like:

  • borgmatic generate ←→ borgmatic create
  • borgmatic validate ←→ borgmatic check

It would be clear from borgmatic --help, of course. Something like:

  • borgmatic generate-config
  • borgmatic validate-config
  • borgmatic upgrade-config

would make the relation to the configuration obvious, but that's perhaps a matter of taste. Thank you for borgmatic!

Yes, probably slightly more work, but even better, I guess. The only issue I see from an end-user perspective is the confusion related to something like: * `borgmatic generate ←→ borgmatic create` * `borgmatic validate ←→ borgmatic check` It would be clear from `borgmatic --help`, of course. Something like: * `borgmatic generate-config` * `borgmatic validate-config` * `borgmatic upgrade-config` would make the relation to the configuration obvious, but that's perhaps a matter of taste. Thank you for borgmatic!
andibm commented 2022-05-07 18:33:07 +00:00
Author
Copy Link

Hm, thinking about bash completion, perhaps the following would be possible, when config- comes first:

  • borgmatic config-generate
  • borgmatic config-validate
  • borgmatic config-upgrade

Entering borgmatic config followed by TAB TAB would then show me the valid commands config-generate config-validate config-upgrade, when provided with a proper bash-completion configuration …

Hm, thinking about bash completion, perhaps the following would be possible, when `config-` comes first: * `borgmatic config-generate` * `borgmatic config-validate` * `borgmatic config-upgrade` Entering `borgmatic config` followed by `TAB TAB` would then show me the valid commands `config-generate config-validate config-upgrade`, when provided with a proper bash-completion configuration …
witten commented 2022-05-08 16:07:07 +00:00
Owner
Copy Link

That makes sense to me. Could even be a sub-action like borg uses for key, etc. Example:

  • borgmatic config generate
  • borgmatic config validate
  • borgmatic config upgrade

Bash completion would be pretty cool, too!

That makes sense to me. Could even be a sub-action like `borg` uses for [`key`](https://borgbackup.readthedocs.io/en/stable/usage/key.html), etc. Example: * `borgmatic config generate` * `borgmatic config validate` * `borgmatic config upgrade` Bash completion would be pretty cool, too!
witten commented 2022-05-09 01:01:13 +00:00
Owner
Copy Link

Ugh, just remembered there's already a borg config that this would collide with. (Unless they could be made to coexist.)

Ugh, just remembered there's already a [`borg config`](https://borgbackup.readthedocs.io/en/stable/usage/config.html) that this would collide with. (Unless they could be made to coexist.)
witten commented 2022-05-26 17:31:55 +00:00
Owner
Copy Link

This ticket isn't started yet, but I wanted to mention that borgmatic bash completion is now implemented in master! Thanks for the suggestion.

This ticket isn't started yet, but I wanted to mention that borgmatic bash completion is now implemented in master! Thanks for the suggestion.
witten commented 2023-03-26 21:54:52 +00:00
Owner
Copy Link

My current thinking on this ticket:

  • upgrade-borgmatic-config (and the corresponding code/tests) can just be outright deleted. borgmatic hasn't had INI-style config since 1.1.0. If keeping the docs for this, they should be updated to mention using the last version of borgmatic to include upgrade-borgmatic-config.
  • generate-borgmatic-config can become borgmatic config generate.
  • validate-borgmatic-config can become borgmatic config validate.
My current thinking on this ticket: * [x] `upgrade-borgmatic-config` (and the corresponding code/tests) can just be outright deleted. borgmatic hasn't had INI-style config since 1.1.0. If keeping the [docs for this](https://torsion.org/borgmatic/docs/how-to/upgrade/#upgrading-from-borgmatic-1.0.x), they should be updated to mention using the last version of borgmatic to include `upgrade-borgmatic-config`. * [ ] `generate-borgmatic-config` can become `borgmatic config generate`. * [ ] `validate-borgmatic-config` can become `borgmatic config validate`.
diivi commented 2023-04-06 12:26:27 +00:00
Collaborator
Copy Link
  • generate-borgmatic-config can become borgmatic config generate.
  • validate-borgmatic-config can become borgmatic config validate.

So did you make a design decision regarding this - #529 (comment) ?

> * `generate-borgmatic-config` can become `borgmatic config generate`. > * `validate-borgmatic-config` can become `borgmatic config validate`. So did you make a design decision regarding this - https://projects.torsion.org/borgmatic-collective/borgmatic/issues/529#issuecomment-4401 ?
witten commented 2023-04-06 16:14:35 +00:00
Owner
Copy Link

I think that quoted text is the design decision. Were you looking for something more specific? Or just a more definitive ruling? 😄

I think that quoted text _is_ the design decision. Were you looking for something more specific? Or just a more definitive ruling? 😄
witten added the
design finalized
 label 2023-04-06 16:15:13 +00:00
diivi commented 2023-04-06 17:22:50 +00:00
Collaborator
Copy Link

No, I meant how borg config and borgmatic config would be separated.

Ugh, just remembered there's already a borg config that this would collide with. (Unless they could be made to coexist.)

No, I meant how `borg config` and `borgmatic config` would be separated. > Ugh, just remembered there's already a borg config that this would collide with. (Unless they could be made to coexist.)
witten commented 2023-04-06 17:47:15 +00:00
Owner
Copy Link

Oh, hah. Good point. Yeah, I haven't given that much thought recently. Some ideas off the top of my head:

  • Make them coexist by passing through plain borgmatic config calls to Borg like a standard borgmatic action, but then hijack borgmatic config generate and borgmatic config validate for the borgmatic-specific functionality. Potentially a little confusing for the user, but then again probably nobody wants to use borg config anyway.
  • Don't support borg config, at least at first. Add borgmatic config validate and borgmatic config generate with the idea that plain borgmatic config could be added later if/when someone wants it. That's basically the same design as the first bullet point, just with less work up-front.
  • Come up with a different action name than config for the borgmatic functionality in this ticket. Nothing decent comes to mind though.
Oh, hah. Good point. Yeah, I haven't given that much thought recently. Some ideas off the top of my head: * Make them coexist by passing through plain `borgmatic config` calls to Borg like a standard borgmatic action, but then hijack `borgmatic config generate` and `borgmatic config validate` for the borgmatic-specific functionality. Potentially a little confusing for the user, but then again probably nobody wants to use `borg config` anyway. * Don't support `borg config`, at least at first. Add `borgmatic config validate` and `borgmatic config generate` with the idea that plain `borgmatic config` could be added later if/when someone wants it. That's basically the same design as the first bullet point, just with less work up-front. * Come up with a different action name than `config` for the borgmatic functionality in this ticket. Nothing decent comes to mind though.
witten commented 2023-06-23 17:15:41 +00:00
Owner
Copy Link

Implemented in main. FYI I went this approach for now:

Don't support borg config, at least at first. Add borgmatic config validate and borgmatic config generate with the idea that plain borgmatic config could be added later if/when someone wants it. That's basically the same design as the first bullet point, just with less work up-front.

Implemented in main. FYI I went this approach for now: > Don't support borg config, at least at first. Add borgmatic config validate and borgmatic config generate with the idea that plain borgmatic config could be added later if/when someone wants it. That's basically the same design as the first bullet point, just with less work up-front.
witten changed title from Rename commands to start with borgmatic- to Move external borgmatic config commands into borgmatic 2023-06-23 17:16:17 +00:00
witten commented 2023-06-25 05:33:14 +00:00
Owner
Copy Link

Just released in borgmatic 1.7.15.

Just released in borgmatic 1.7.15.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Label
design finalized
Milestone
No items
No Milestone
Assignees
Clear assignees
diivi import_bot witten
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#529
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?