Following up on previous commit, added spinner to all repo actions.
Also introduced on_all_spinner helper function, which is a version of
on_all, but intended for a single repo action (not a composed one like
quick), that takes care of managing the spinner.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Spinners are a blinking lights UX component. Ideally, a flag will be
added to run silently.
This only implements a sketch for using spinners when doing a quick
sync.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Fixed tests to work with the new hashmap based architecture.
Introduced some handy helper functions in main.rs testing that I might
wanna move to the impl block of config later.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
This is an implementation of the nested hashmap architecture, outlined
in architecture.md, however, with a hashmap instead of a btreemap.
This is ultimately just a sketch.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
This commit introduces on_all() on the config struct.
This unifies behaviour for iterating over all repos
in the config.
I'm introducing this to make testing various architectural
choices a breeze.
NOTE: Ideally, GitRepo should also be made generic, allowing
other types of repos at some point.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
I've started to document parts of the design process, mostly for my own
sake.
Having this around later will be helpful, and it also means I can point
smarter people here to quickly explain more complicated issues.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Naive category implementation.
Works somewhat, including part of tests.
However, I realize now that perhaps, having unique category names in
nescesarry for subcommands.
On the other hand, allowing them to be non unique would allow splitting
up category definitions.
But finding the category in a vec would be slow...
...and I want a lot of categories probably...
I'm still working on this... here is one way to do it ᕕ( ᐛ )ᕗ
Saved in the git log for posterity.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Flags indicate what operations should be masked on a repo.
This is done in a way that is relatively more pleasurable to configure,
and should reduce the amount of breaking changes long term.
Overally, a very nice commit :D
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Commented out code that could potentially be destructive, right now it's
only a sketch, and if the unimplemented macro was removed one might be
mistaken thinking the associated function was intended for use.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Made the GitRepo associated functions easier to debug, by providing
additional output of the struct when running the git command on the repo
fails.
Also removed commented out code in main.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
This still has an issue, because tests cannot run with network inside of
the flake.
When this is solved, the code just needs to be refactored and it's
ready.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
The flake is still not fully functional.
First, it seems nescesarry to get a solid system for relative paths,
so that we can run tests inside of a nix build.
To iterate on this, use `nix flake check`.
Refactored Links::link implementation to be able to deal with several possible scenarios:
file already linked (happy case)
link to different file exists
non link file exists
broken symlink exists
no file exists (happy case)
generic failure
Also attempted to make the code more readable than previous attempt. Admittedly, still needs some work.
Refactored Links::link implementation to be able to deal with
several possible scenarios:
- file already linked (happy case)
- link to different file exists
- non link file exists
- broken symlink exists
- no file exists (happy case)
- generic failure
Also attempted to make the code more readable than previous attempt.
Admittedly, still needs some work.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Added licenses to files in src.
Implemented flags:
- warranty
- license
Added license notice to help.
Refactored parts of the code.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Moved the help template into its own const, and concatenated it with the
interactive notice to append it to the help output.
Also, adjusted the license, warranty, and notice strings for increased
readability.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Made the clap Parser able to be run without a subcommand, by wrapping
the subcommand field of the Parser struct in an Option<Command>.
Further destructured the subcommand arms fields in main with Some(),
and made the default case None just return ().
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Implemented the flag arms for license, warranty in main,
but this will not work before we make the clap Parser able
to be run without a subcommand, by wrapping the subcommand
field of the Parser struct in an Option<Command>.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Made the following utils/strings consts public
- INTERACTIVE_NOTICE
- INTERACTIVE_LICENSE
- INTERACTIVE_WARRANTY
This is to allow their use in the flags match in main.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Added an arm to the match statement for parsing flags in main.
Using the pattern and hopefully ongoing convention of making
unimplemented arms indicated by using the unimplemented!() macro.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
My room temperature is approaching that of my processor.
Hydrating is very important, in order to keep myself in peak shape for
coding, I took a tactical water break.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Added the --warranty flag.
Removed part of docstring that said the --license would give full-text.
This is wrong, as will be implementing the shorter notice.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Added these three constants to utils/strings:
- INTERACTIVE_NOTICE
- INTERACTIVE_LICENSE
- INTERACTIVE_WARRANTY
These were based of the license text's notices for interactive programs,
found in the "How to Apply These Terms to Your New Programs" section.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
Strings representing where to run commands where one of:
.current_dir(&(self.path.to_owned() + &self.name))
.current_dir(format!("{}{}", &self.path, &self.name))
Decided to change all instances to the latter, as asking people seemed
to prefer it for readability.
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
