I never would have guessed just how many things I'm missing. It looks
like it even worked out that there is both a binary and a library, which
is not something I had considered. Neat.
I credited Johannes Schauer Marin Rodrigues <josch@debian.org> with the
original debian/rules way back at the start of the packaging branch. It
seemed like good traceability, at the very least.
Now, the rules file is just a bit of boilerplate. I don't think anyone
needs particular credit for this thing, so I'm dropping the explicit
mention.
These don't do anything. I've compared against some other Rust packages
(some ProxmoxVE stuff) and the output of debcargo against this crate
(from crates.io, now that it's up). Neither contain these targets. I'm
fairly confident I don't need them at all.
See "https://wiki.debian.org/Teams/RustPackaging/Policy"
In section "Library package structure", the policy manual explains that
this file is meant to exist in the Debian package (i.e.: it's not
generated during the build) and should contain the SHA256 checksum of
the upstream crate.
The crate's internal arrangement can change depending on which version
of Cargo was used to create it. This checksum is from Rust 1.93, the
current stable at time of writing. Debian 13's Rust 1.85 produces a
different file with a different sum. I'm not sure what to do about that
right now.
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.
