| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
(In most cases, by writing the documentation;
in tests, by permitting the documentation to be missing.)
|
| |
|
|
|
|
|
| |
The new (dubiously named) `Figment::extract_lossy` method
can treat decode numbers from strings, and booleans from numbers or
strings. This makes the behavior compatible with config-rs, and
should (I hope) finally allow us to migrate.
|
| |
|
|
|
| |
There are probably ways to make this a bit more elegant, but at
least the tests still pass.
|
| |\
| |
| |
| |
| | |
Encapsulate usage of config-rs inside tor-config.
See merge request tpo/core/arti!2040
|
| | |
| |
| |
| | |
This will let us replace Config with something better.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #790
|
| |
|
|
| |
So, this is not a semver addition.
|
| | |
|
| |
|
|
| |
str can always be made into a PathBuf.
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the new upstream version (published by me, recently).
It has the same MSRV and one breaking change:
The caller who specifies a home dir function for substituting into
strings, must now supply a string, not Path. Previously shellexpand
would allow the caller to supply non-unicode data, and then simply not
substitute it. That was an infelicity in the shellexpand API.
Now this infelicity is pushed into our code. The overall behaviour of
Arti hasn't changed as a result. And it seems reasonable to me.
shellexpand 3.x also has a module for expanding Paths instead, in
response to requests for this filed as upstream tickets. We *could*
use that but I am not sanguine about that approach: the Pathness would
spread throughout much of our config and file handling code.
I think we should at the very least postpone trying to work with
invalid-unicode-paths as long as we can.
|
| | |
|
| |
|
|
|
|
|
| |
This lint exists for perf reasons, and this is rarely relevant in
tests.
Using double quoted str is generally cognitively less burdensome.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
`${PROGRAM_DIR}` expands to the equivalent of
`std::env::current_exe().parent()`, with appropriate unwrapping and
conversions.
It is expected to be useful for finding the locations of pluggable
transports in some kinds of bundles.
Closes #586.
|
| |
|
|
|
|
| |
Found these by disabling the nightly dbg macro special case. Now, we
have a mechanism for globally adding suppressions to tests, we can use
that instead.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This was done because Nightly Rust complained about these, despite
them all being in tests. That is now fixed upstream:
https://github.com/rust-lang/rust-clippy/issues/8758
https://github.com/rust-lang/rust-clippy/pull/8838
This reverts commit 9d26a91886990b08dc5b6033c290d417489c61fc.
|
| |
|
|
| |
This should satisfy our CI and turn it green again.
|
| |
|
|
|
|
| |
Use MessagePack.
Signed-off-by: Ian Jackson <[email protected]>
|
| |
|
|
|
|
| |
And provide round-trip tests.
As per https://gitlab.torproject.org/tpo/core/arti/-/issues/371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document that this can contain either a string for expansion, or a
literal PathBuf not for expansion.
Rename the `from_path` method to `new_literal`: a very important
difference is whether it gets expanded - less important than the Rust
type. Also, now it takes `Into<PathBuf>`, which avoids a needless
clone.
(We don't change the API in `arti-client` because
`&tempfile::Tempdir()` doesn't implement `Into<PathBuf>`, so
`arti-client` has to have some new `as_ref` calls.)
Provide accessors `as_unexpanded_str` and `as_literal_path`. The
deserialisation already makes this part of the stable API,l so not
pvoding accessors seems just obstructive. They are useful for tests,
too.
Add tests for the new entrypoints, and for deserialisation of both
variants from TOML (via config, or directly) and JSON.
|
| |
|
|
|
|
|
|
| |
We introduce LiteralPath struct, so that a literal path deserialises
from
some_path = { literal: "actual path string" }
This makes the deserialisation unambiguous.
|
| | |
|
| |
|
|
| |
This required a few new ErrorKinds.
|
| | |
|
| |
|
|
| |
Closes #246.
|
| |
|
|
|
|
|
|
| |
The sane_defaults() call is now the same as you get from a default
builder: by convention, we just call that method Default::default().
The with_directories() constructor makes more sense as a constructor
for the TorClientConfigBuilder than for TorClientConfig.
|
| | |
|
| |
|
|
|
| |
Doing this is necessary for reconfiguration support, and will help a lot
with testing, too.
|
| |
|
|
|
|
|
|
| |
Since these shell-variables are hardwired to use org.torproject.Arti as
the program name, it isn't appropriate to call them "app-specific".
If we someday reinstate APP_FOO, it should be based on a user-provided
application name.
|
| |
|
|
|
|
|
|
| |
In order to handle explicitly specified path buffers directly, we now
let CfgPath be either a string (that gets expanded) or a PathBuf
(that doesn't).
This simplifies TorClientConfig::with_directories()
|
| |
|
|
|
|
|
|
| |
Now every section that the two configuration objects share has the
same type and name. This should help us in documenting our configuration
in a way that doesn't confuse people.
There is still lots of API work to go.
|
| |
|
|
|
|
|
|
| |
To do this at all neatly, I had to split out `tor-config` from
`arti-config` again, and putting the lower level stuff (paths,
builder errors) into tor-config. I also changed our use of
derive_builder to always use a common error type, to avoid
error type proliferation.
|
| |
|
|
|
| |
I'm about to make tor-config a higher-level module, so it can't be a
dependency for tor-config.
|
| | |
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
