The Debian 12 dependency versions can go away since I'm no longer
targetting it. The Debian Sid versions haven't been checked in months,
and I'm not actually targetting it *either* (never have been). They can
both go away.
I'm deciding that I'll only support the latest stable release of
Debian. Somehow I doubt anyone is using this tool, and those who do are
unlikely to need an even longer support window than Debian's stable
release period.
This change bumps the dependencies to match those available in Debian
13. Some upgrades would have already happened, while others are blocked
by the SemVer rules.
For example, Clap 4.0 to 4.5 would happen automatically, but TOML 0.5 to
0.8 would not.
There are two concepts here and that should be more clearly indicated.
Introduce the file format with some examples, then talk about where
those files are found.
I need to introduce the idea that "projects" are actually file paths,
and that these paths are the keys for the key-value stores that are the
config files.
...but without saying "HashMap" because that's really an implementation
detail.
The auth tokens can now be loaded from the config files, so I need to
mention that.
I took the opportunity to revise the explanation of when auth is
required. Now it has a more obvious example of how it depends on
instance configuration.
I don't need to have nearly so much information explaining how to use
optional command line arguments. The quirk about the "repo" needing to
be a URL fragment somewhat justified the extra explanation, but that's
gone now.
Instead, a short, up-front section stating which bits are required and
where the program will try to get them.
It all falls into place! I had been dreading doing this bit, but after
updating the usage guide I realized the CLI args should be split, too.
Which finally means that I can just glue on the PWD name as a final
fallback for the repo name.
Try the args, then the config file(s), then PWD. If nothing works, the
user is in a world of hurt. Bail out.
There's a new inconsistency, however. The previous URL and FQRN
arguments are no longer mandatory but their description makes it seem
as though they are.
The configuration file loading is complete and seems to work the way I
expect. I still need to do an improved project guessing system, and it
would be smart to allow the user to explicitly enter a config file to
use.
If there is no project-specific configuration, use a default one
instead. It still needs to be merged with the "[all]" one, assuming that
exists.
Now to do the same thing for the all-table.
I started to replace this with an infallible `try()` implementation
before realizing that this exists specifically to filter out the
no-such-table result. That isn't an error *in this context*, which is
what the try_from() is doing for me.
The project path value gets set as a side-effect of loading the named
configuration table. Which... actually means this information isn't
important. I know it going in, and I know it coming out. I think the
real fix is to delete the field.
Load the configuration for the current directory. The project guessing
mechanism isn't here, yet, so this will have to do.
First take the properties set via Args. This will also capture the
values set through environment variables. For anything that's missing,
try to fill it with the info from the configuration files. In the event
that there isn't enough information, new error types have been added to
signal mis-use.
It's the removed section from the get_config() function, but with an
extra Vec<_> creation. This is necessary here because the strings from
the environment variable don't live long enough for lazy evaluation.
Now I can actually test the function!
The previous search locations are still what I'll want for normal
operation, though, so I'll be putting in a new util function to generate
them.
"Now finish drawing the Owl."
I started assembling everything before realizing that I've been thinking
about the program backwards. The `WholeFile` struct is completely
unnecessary, as are several of the functions that help to create it.
I forgot that I don't need to collect all the project tables, only the
"[all]" table, and what ever the user is currently using. I want the
structure of a Map, not a list. I don't want this wrapper, I want the
toml::Value directly.
The implementation is dead simple, and pretty dumb. I'm not going to
figure out all the different IO errors I might see. Instead, the
function will report that it couldn't read the file and call it good.
This function almost writes itself. I need a thin layer to handle the
file IO errors and report them appropriately, and then all the magic is
a pass-through of the existing read_conf_str.
I've made basic unit tests for the most obvious scenarios. The test for
missing-file behavior is incomplete because I need to create a new error
variant.
I'm beginning work on the file reading functions, so I need some files
to read in my tests. I'll also need the WholeFile struct to compare
against.
The input string has been moved out into a file and put back into the
test fixture with `include_str!()`. The WholeFile construction has been
moved to a util function so I can reuse it in another test.
The empty configuration string is some kind of an error, but I'm not
sure where and how to handle it. It should be treated as a soft error,
where I fall back to some hardcoded defaults.
There's a logic hole at the moment: The error I'm actually getting right
now is "NoSuchTable" because the "[all]" table doesn't exist. For a
totally empty config file, the above response should be used. But what
about a non-empty conf file? Is a missing "[all]" valid or not? For now,
assert the loader returns *an* error and leave behind a TODO for later.
I like being able to chain methods instead of using a temporary variable
in between, so I've made one single function like I'm doing the builder
pattern.
But not really because there's nothing to build or finalize and such.
Don't repeat yourself. These property reading routines are actually
methods on the PartialConfig struct, so make them *actually* methods.
Because the table doesn't know it's own name, the path-specific config
needs to be updated with that external knowledge.
