borgmatic-collective/borgmatic
borgmatic-collective
/
borgmatic
15
57
Fork 40
Code Issues 53 Pull Requests 1 Actions Packages Releases 121 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
main
spot-check
1.8.10
1.8.9
1.8.8
1.8.7
1.8.6
1.8.5
1.8.4
1.8.3
1.8.2
1.8.1
1.8.0
1.7.15
1.7.14
1.7.13
1.7.12
1.7.11
1.7.10
1.7.9
1.7.8
1.7.7
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.1
1.7.0
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.24
1.5.23
1.5.22
1.5.21
1.5.20
1.5.19
1.5.18
1.5.17
1.5.16
1.5.15
1.5.14
1.5.13
1.5.12
1.5.11
1.5.10
1.5.9
1.5.8
1.5.7
1.5.7.dev0
1.5.6
1.5.5
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.22
1.4.21
1.4.20
1.4.19
1.4.18
1.4.17
1.4.16
1.4.15
1.4.14
1.4.13
1.4.12
1.4.11
1.4.10
1.4.9
1.4.8
1.4.7
1.4.6
1.4.5
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.26
1.3.25
1.3.24
1.3.23
1.3.22
1.3.21
1.3.20
1.3.19
1.3.18
1.3.17
1.3.16
1.3.15
1.3.14
1.3.13
1.3.12
1.3.11
1.3.10
1.3.9
1.3.8
1.3.7
1.3.6
1.3.5
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
1.2.18
1.2.17
1.2.16
1.2.15
1.2.14
1.2.13
1.2.12
1.2.11
1.2.10
1.2.9
1.2.8
1.2.7
1.2.6
1.2.5
1.2.4
1.2.3
1.2.2
1.2.1
1.2.0
1.1.15
1.1.14
1.1.13
1.1.12
1.1.11
1.1.10
1.1.9
1.1.7
1.1.6
1.1.5
1.1.4
1.1.3
1.1.2
1.1.1
1.1.0
1.0.3
1.0.2
1.0.1
1.0.0
0.1.8
0.1.7
0.1.6
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
0.0.7
0.0.6
0.0.5
0.0.4
0.0.3
0.0.2
Labels
Clear labels   
bug

   
data loss

   
design finalized

   
good first issue

   
new feature area

   
question / support

   
security

   
waiting for response
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

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

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?