aboutsummaryrefslogtreecommitdiff
path: root/crates/arti-config
Commit message (Collapse)AuthorAgeFilesLines
...
* Run maint/add_warning crates/*/src/{lib,main}.rsIan Jackson2022-06-231-0/+3
| | | | Update all lint blocks
* Merge branch 'lint' into 'main'Ian Jackson2022-05-311-0/+35
|\ | | | | | | | | | | | | lints: Make lint blocks consistent and ensure they stay that way Closes #469 See merge request tpo/core/arti!557
| * lints: Make lint blocks consistentIan Jackson2022-05-311-1/+3
| | | | | | | | The remaining consequences of running add_warning
| * lints: Add let_unit_value allow to all cratesIan Jackson2022-05-311-0/+1
| | | | | | | | | | From running add_warning, with manual picking of the right hunks/lines.
| * lints: Add lint block delimiters to every crateIan Jackson2022-05-311-0/+2
| | | | | | | | | | | | This was the result of: maint/add_warning crates/*/src/{lib,main}.rs and then manually curating the results.
| * lints: arti-config: Re-add standard lint listIan Jackson2022-05-311-0/+30
| | | | | | | | We are going to make lints the same for every crate.
* | arti-config: Change description of tombstone crateIan Jackson2022-05-311-1/+1
|/ | | | | | | | I was looking to see if we could delete this altogether but I discovered that on lib.rs the description does not say it's a removed crate, in the summaries. Fix this.
* Semantic version changes for Arti 0.4.0 releaseNick Mathewson2022-05-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | I followed the following procedure to make these changes: * I used maint/changed_crates to find out which crates had changed since 0.3.0. * I used grep and maint/list_crates to sort those crates in topological (dependency) order. * I looked through semver_status to find which crates were listed as having semver-relevant changes (new APIs and breaking changes). * I scanned through the git logs of the crates with no semver-relevant changes listed to confirm that, indeed, they had no changes. For those crates, I incremented their patch-level version _without_ changing the version that other crates depend on. * I scanned through the git logs of the crates with no semver-relevant changes listed to confirm that, indeed, they had no obvious breaking changes. * I treated all crates that depend on `arti` and/or `arti-client` as having breaking changes. * I identified crates that depend on crates that have changed, even if they have not changed themselves, and identified them as having a non-breaking change. * For all of the crates, I used `cargo set-version -p $CRATE --bump $STATUS` (where `STATUS` is `patch` or `minor`) to update the versions, and the depended-upon versions.
* update readmestrinity-1686a2022-05-251-0/+2
|
* Abolish arti-config, replacing with tombstone crateIan Jackson2022-05-133-80/+8
|
* arti-config abolition: Move functionality to tor-configIan Jackson2022-05-131-233/+1
| | | | | | | | | | | | | | | | | This crate no longer has any reason to exist. All its remaining functionality is generic enough to go into tor-config. In this commit, we move the contents of lib.rs into a new file in tor-config. It contains: * Code motion * The minimal "mod" and "use" changes * The minimal doc comment * A new a compat alias for ConfigurationSources. The compat alias is there because various crates currently speak of arti_config::ConfigurationSources and it is most convenient to fix them up after the type is available in tor_config.
* arti-config: Move default config file test to arti-clientIan Jackson2022-05-131-10/+0
| | | | | | That's where this definitions is now. This test ought to have been moved in Move default_config_file() into arti-client
* Fix comment locationIan Jackson2022-05-131-2/+2
|
* config load: Move mistrust checking to load()Ian Jackson2022-05-131-15/+34
| | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/issues/472 Experimentation convinced me the Mistrust should be within the ConfigurationSources.
* ARTI_DEFAULTS: Move to arti crateIan Jackson2022-05-123-192/+0
|
* config defaults: No longer apply ARTI_DEFAULTS in load()Ian Jackson2022-05-121-4/+0
| | | | | | | | This is redundant, because the defaults have to be supplied by the config builders (usually via builder default attributes). That this is actually done and correct is tested by the `default_config()` test case in arti/src/cfg.rs.
* arti-config: Move cmdline to tor-configIan Jackson2022-05-112-207/+1
| | | | | | This does not know anything about arti, only about TOML and Config. Code motion, plus necessary import adjustments.
* Move default_config_file() into arti-clientIan Jackson2022-05-111-6/+1
| | | | This will let other embedders use it.
* ConfigurationSources: Have the generics take Into<owned>Ian Jackson2022-05-111-12/+12
| | | | | | | | | | These generic arguments weren't consistent. It doesn't make sense ot insist on getting a borrowed type and then cloning it. So tidy things up in the direction of taking owned values, which is what ConfigurationSources actually needs. (My personal preference would be &dyn to avoid monomorphisation code bloat but that was controversial last time I proposed it somewhere.)
* ConfigurationSource: Move "usual" logic for constructionIan Jackson2022-05-112-0/+47
|
* default_config_file(): Have it return Result, not OptionIan Jackson2022-05-111-3/+3
| | | | Discarding this error is not right.
* ConfigurationSource: Rename new to new_emptyIan Jackson2022-05-111-1/+1
| | | | | This emphasises its nature. We're going to provide a more cooked constructor in a moment.
* Bump the version of every* crate to 0.3.0Nick Mathewson2022-05-061-4/+4
| | | | * Except for safelog and fs-mistrust, which are new.
* Switch to derive_builder_arti_forkIan Jackson2022-05-061-1/+1
| | | | | | | | | For reference, the git source for this crate (and the others in its workspace) currently lives in my personal github account (ijackson). If this fork turns out to be long-lived and gains features and/or users, it would be good to move it to a gitlab somewhere. I have granted Nick crate ownership on the crates.io system.
* Merge branch 'derive-builder-git-fixup' into 'main'eta2022-04-271-1/+1
|\ | | | | | | | | derive_builder: Use git dep everywhere, rather than cargo patch See merge request tpo/core/arti!477
| * derive_builder: Use git dep everywhere, rather than cargo patchIan Jackson2022-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `[patch]` approach causes the tree not to build when used as a dependency, unless the `[patch]` is replicated into the depending project. Instead, replace our `derive_builer =` dependencies with a reference to a specific git commit: perl -i~ -pe 'next unless m/^derive_builder/; s#"(0\.11\.2)"#{ version = "$1", git = "https://github.com/ijackson/rust-derive-builder", rev = "ba0c1a5311bd9f93ddf5f5b8ec2a5f6f03b22fbe" }#' crates/*/Cargo.toml Note that the commitid has changed. This is because derive_builder is in fact a workspace of 4 crates. 3 of them are of interest to arti itself (the 4th exists only for testing). So the same "add git revision" treatment had to be done to the `derive_builder` and `derive_builder_macro` crates. Each dependency edge involves a new commit in the derive_builder workspace, since we can't create a git commit containing its own commitid. (We want to use commits, rather than a branch, so that what we are depending on is actually properly defined, and not subject to the whims of my personal github namespace.) There are no actual code changes in derive_builder.
* | Fix grammar and typosSamanta Navarro2022-04-272-2/+2
| |
* | Merge branch 'upgrade_dependencies' into 'main'eta2022-04-271-1/+1
|\ \ | |/ |/| | | | | | | | | Upgrade various dependencies, now that we are MSRV 1.56 Closes #313 and #334 See merge request tpo/core/arti!476
| * Bump to config 0.13Nick Mathewson2022-04-261-1/+1
| |
* | Merge branch 'download-schedule' into 'main'Nick Mathewson2022-04-261-4/+4
|\ \ | |/ |/| | | | | DownloadSchedule: Introduce Builder See merge request tpo/core/arti!473
| * DownloadSchedule: Rename field to "attempts"Ian Jackson2022-04-261-4/+4
| | | | | | | | | | | | | | This is actually a number of *attempts* not a number of *retries*. The setter method was already called "attempts". This chnages the deserialisation of the config.
* | Bump every crate's edition to 2021.Nick Mathewson2022-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | This is an automated change made with a perl one-liner and verified with grep -L and grep -l. Some warnings are introduced with this change; they will be removed in subsequent commits. See arti#208 for older discussion on this issue.
* | Add 'rust-version = "1.56"' to every Cargo.toml file.Nick Mathewson2022-04-251-0/+1
| | | | | | | | | | | | | | This change was made automatically with a perl one-liner, and confirmed with `grep -L`. The `rust-version` field itself was introduced in 1.56.0.
* | Reformat all not-yet-reformatted Cargo.toml files.Nick Mathewson2022-04-251-6/+8
|/ | | | | There are no semantic changes here; only formatting. This is in preparation for other changes (wrt MSRV and edition)
* Use git source for derive_builder for now, for sub_builder featureIan Jackson2022-04-211-1/+1
| | | | | | | | | | | | | | | This commitid is the current head of my MR branch https://github.com/colin-kiegel/rust-derive-builder/pull/253 https://github.com/ijackson/rust-derive-builder/tree/field-builder Using the commitid prevents surprises if that branch is updated. We will require this newer version of derive_builder. The version will need to be bumped again later, assuming the upstream MR is merged and upstream do a release containing the needed changes. We will need the new version of not only `derive_builder_core` (the main macro implementation) but also`derive_builder` for a new error type.
* Bump all arti*, tor* crates to 0.2.0Nick Mathewson2022-04-011-4/+4
| | | | | | | | Not all of these strictly need to be bumped to 0.2.0; many could go to 0.1.1 instead. But since everything at the tor-rtcompat and higher layers has had breaking API changes, it seems not so useful to distinguish. (It seems unlikely that anybody at this stage is depending on e.g. tor-protover but not arti-client.)
* Use a lower default for max_retries.Nick Mathewson2022-03-301-1/+1
| | | | | | | | | | The older default seems (experimentally) to be ridiculously high. Generally, if we can't build a circuit within a handful attempts, that circuit has already timed out... unless there is a fast-failure condition, in which case we're just hammering the network (or our view of it.) Found with `arti-testing` for #329.
* Run rustfmt to tidy up importsIan Jackson2022-03-211-1/+1
|
* Move ApplicationConfig to arti crateIan Jackson2022-03-212-30/+1
| | | | Code motion and import fixups.
* Move ProxyConfig to arti crateIan Jackson2022-03-212-51/+1
| | | | | | | We put this in cfg.rs, rather than (say) socks.rs, because it has config relating to both socks.rs and dns.rs. Code motion and import fixups.
* Move logging configuration from arti_config::options to arti::loggingIan Jackson2022-03-212-127/+2
| | | | Code motion and import fixups.
* Move ArtiConfig to new arti::cfg moduleIan Jackson2022-03-212-261/+5
| | | | Code motion and import fixups.
* derive_builder: Switch to upstream 0.11Ian Jackson2022-03-161-1/+1
| | | | | | | | | This has the different syntax for builder field attributes than what I originally proposed in my MR, and which therefore is in the pinned branch. My upstream MR for the field attributes feature was morged: https://github.com/colin-kiegel/rust-derive-builder/issues/239
* add udp to runtimetrinity-1686a2022-03-141-0/+10
|
* rustfmtIan Jackson2022-03-111-10/+15
|
* Make ArtiConfigBuilder contain a TorClientConfigBuilderIan Jackson2022-03-111-135/+19
| | | | | | | This is an API break: now one must use `.tor()` to access the Tor configuration parts. But it is not a config file format break, because `#[serde(flatten)]`.
* Drop remaining conversion from FooConfig to FooConfigBuilderIan Jackson2022-03-071-29/+0
|
* Have ArtiConfig contain a TorClientConfig, and drop builder retconIan Jackson2022-03-071-134/+13
| | | | | | | | | | | | | | | | | | | Replace the recapitulation of TorClientConfig fields in ArtiConfig and instead just have it contain one. This is part of #374. The conversions from ArtiConfig back to ArtiConfigBuilder and TorClientConfigBuilder would need to change, but, since we don't want them anyway, No longer impl Deserialize for ArtiConfig. (As per #371 this will want to become a private type.) No longer impl From<ArtiConfig> for ArtiConfigBuilder and TorClientConfigBuilder. And abolish tests of that code. (This all has to be in one commit, because previously ArtiConfig::tor_client_config used the validated-to-builder config retcon.)
* Provide way to get TorConfigBuilder from ArtiConfigBuilderIan Jackson2022-03-071-0/+27
| | | | | | This is needed according to #372, where we observe that builders ought not to be generated from validated structs. So we need this conversion.
* Derive Deserialize for handwritten ArtiConfigBuilderIan Jackson2022-03-071-1/+16
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 00:27:12 +0000