[feature request] label/tag a repo #635
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#635
Loading…
Reference in New Issue
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?
What I'm trying to do and why
Label a repo, to be able to use
--repository label1
instead of the full path copypasted fromborgmatic list
. Useful when using multiple config files with/etc/borgmatic.d
, or multiple repositories in the same file.Syntax could be
Problem is that it uses a dict instead of the current list, and it breaks compatibility.
If a label is set, it could be used in
borgmatic list --short
Mount a backup
This is a great idea! I think the string vs. dict thing could be sidestepped by auto-converting any list of strings into a list of dicts internally.. There is precedent for doing that with other configuration options in borgmatic.
This is a problem that I face too, I would like to work on the solution!
Will explore the code a little, anything you have to sugget @witten ?
Sure! The auto-converting of lists to dicts internally I mentioned in the last comment could be done in the existing
borgmatic/config/normalize.py:normalize()
. That way, "old-style" configuration files would continue to work. (Which suggests repository labels should be optional.) There are also a number of places throughout the borgmatic source that expectrepositories
to be a list of strings instead of list of dicts, so those would have to be updated as well.Additionally, the code that resolves repository names (matching a repository specified on the command-line to a repository specified in configuration) is at
borgmatic/config/validate.py:repositories_match()
. That could be enhanced to support matching repositories by label and not just path, although the relevant configuration would have to get passed in for that to work.Lastly, code that looks like this throughout the borgmatic source would probably need updating to use repository labels (if set):
I checked the current
schema.yaml
and did this:But this expects the repositories to be an array of objects instead of an array of strings.
I couldn't understand your discussion about "lists to dicts", here I should be getting a list of dicts like this right?
What should I convert this data structure to? Assuming earlier it used to be
If the label does not need to be handled in
normalize.py
, I can convert the list of dicts(1) back to the list of strings(2), effectively ignoring it here and only handling it in the places where you mentioned matching/handling of a repository name takes placeYour new schema and resulting list of dicts looks completely correct to me. I'm assuming that will be the new standard data structure for
repositories
going forward. So what I meant by converting "lists to dicts" is that if the old data structure, e.g.["x/y/z"]
(a list of strings), happens to be present in a configuration file, it needs to get converted to the new data structure (a list of dicts) before the schema is applied. That way all the borgmatic code can get updated to expect the new structure and can forget all about the old structure (outside ofnormalize.py
).To summarize, the general order of events is:
normalize.py
.This is all already in place today, and my suggested change is just to update
normalize.py
. And also of course the schema changes you've already made!Please let me know if any of this doesn't make sense.
eoli3n referenced this issue2023-03-15 13:26:59 +00:00
Released in borgmatic 1.7.10! Thanks to @diivi for doing this work!
I just tested this, and notice that a little part is missing.
Maybe not important, but
--short
doesn't use the label, it still uses the full path.But It should return
That's the cherry at the top of that feature :P
Makes sense! Thanks for bringing this to our attention.
I did part of this for some of the high-level functions, but more work will be needed to change the log statements for the remainder of the code base.
hey @witten, did you end up solving this? Sorry for the late response, my exam just ended.
Looks like
repository.get("label", repository["path"])
throughout the codebase is done to implement this?Hey @diivi! Glad to hear you've gotten through your exams. You are correct, what you propose is most of the work remaining on this ticket. The other 90% though is passing through the full
repository
dict to everywhere in the code that needs it for this!