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.
The `lconf()` function will eventually load the whole file, but for now
it reads in only the "[all]" table.
That "[all]" table will be used as the global fallback when per-project
settings are left unspecified.
The unit test "passes" but only because I've discarded those per-project
configs from the expected result. This is just so I can see clearly that
the all-table is loading properly.
The get_property function needs to say that there is no property so that
the caller can respond appropriately. I'm going to need to frequently
respond to the "no such property" path by treating it as *not* an error.
If the config file doesn't specify a property, that's not an error, it's
just not specified and the default should be used instead. This util fn
makes that a bit more ergonomic.
I don't want to remember to construct a `String` every single time I
want to call this function with a string literal. So I won't.
Make the functions generic over anything that implements the ToString
trait.
