History

Nick Mathewson 96875ea208 Bump crate versions in preparation for Arti 1.0.0 release. Because we want to work more on ensuring that our semver stability story is solid, we are _not_ bumping arti-client to 1.0.0 right now. Here are the bumps we _are_ doing. Crates with "minor" bumps have had API breaks; crates with "patch" bumps have had new APIs added. Note that `tor-congestion` is not bumped here: it's a new crate, and hasn't been published before. ``` tor-basic-utils minor fs-mistrust minor tor-config minor tor-rtcompat minor tor-rtmock minor tor-llcrypto patch tor-bytes patch tor-linkspec minor tor-cell minor tor-proto minor tor-netdoc patch tor-netdir minor tor-persist patch tor-chanmgr minor tor-guardmgr minor tor-circmgr minor tor-dirmgr minor arti-client minor arti-hyper minor arti major arti-bench minor arti-testing minor ```		2022-09-01 08:59:49 -04:00
..
src	Fix a rustdoc link error.	2022-08-31 12:24:39 -04:00
Cargo.toml	Bump crate versions in preparation for Arti 1.0.0 release.	2022-09-01 08:59:49 -04:00
README.md	Fix typos	2022-06-05 18:47:51 +03:00
semver.md	Improve error from bad escapes in a toml config.	2022-08-25 15:04:52 -04:00

README.md

tor-config

tor-config: Tools for configuration management in Arti

Overview

This crate is part of Arti, a project to implement Tor in Rust.

It provides types for handling configuration values, and general machinery for configuration management.

Configuration in Arti

The configuration for the arti command line program, and other programs which embed Arti reusing the configuration machinery, works as follows:

We use tor_config::ConfigurationSources to enumerate the various places where configuration information needs to come from, and configure how they are to be read. arti uses [ConfigurationSources::from_cmdline].
[ConfigurationSources::load] actually reads all of these sources, parses them (eg, as TOML files), and returns a [config::Config]. This is a tree-structured dynamically typed data structure, mirroring the input configuration structure, largely unvalidated, and containing everything in the input config sources.
We call one of the tor_config::resolve family. This maps the input configuration data to concrete ConfigBuilder s for the configuration consumers within the program. (For arti, that's TorClientConfigBuilder and ArtiBuilder). This mapping is done using the Deserialize implementations on the Builders. resolve then calls the build() method on each of these parts of the configuration which applies defaults and validates the resulting configuration.

It is important to call resolve once for all the configuration consumers, so that it sees a unified view of which config settings in the input were unrecognized, and therefore may need to be reported to the user. See the example in the [load] module documentation.
The resulting configuration objects (eg, TorClientConfig, ArtiConfig) are provided to the code that must use them (eg, to make a TorClient).

See the tor_config::load module-level documentation. for an example.

⚠ Stability Warning ⚠

The design of this crate, and of the configuration system for Arti, is likely to change significantly before the release of Arti 1.0.0. For more information see ticket #285.

License: MIT OR Apache-2.0