gix-testtools: Upgrade versions of gix crates #1510

joshtriplett · 2024-08-11T23:09:43Z

This avoids duplicate dependencies in packages depending on both gix and
gix-testtools.

This avoids duplicate dependencies in packages depending on both gix and gix-testtools.

joshtriplett · 2024-08-11T23:09:58Z

Would it be possible to get a gix-testtools release based on this?

Also, is there some process that could avoid having gix-testtools get out of sync?

Byron · 2024-08-12T07:20:13Z

Actually, I don't think I can do that as it will break the ability of cargo smart-release to perform a release of gitoxide. Publishes fail if the test-tools use dependencies in the workspace, and using a separate set of crate versions (that also have to be one major version in the past, ideally) was the only workaround I could find. (gix-testtools seems to be special as it's used as dev-dependency in crates that are also depend on it, it's a cycle.)

I'd also love to not have this special-case, but it will probably need more time than I can invest into cargo smart-release to find a proper fix for it - it's a complex tool that was rewritten once already, yet is totally under-tested. My hopes are that one day, cargo smart-release will only be used to set the crate versions update changelogs, while cargo publish can be used to publish everything in the right order - then it should be possible to remove this special case.

The previous commit added `gix-testtools` (by relative path) as a dev dependency of `gix-index`, so `gix_testtools::size_ok`. Because `gix-testtools` itself depends on `gix-index` -- at an earlier version to not break releasing with csr (see discussion in GitoxideLabs#1510 for general info) -- this causes `cargo`, when running in the top level workspace directory, to consider `-p gix-index` without an explicit version to be ambiguous. This made the full CI `test` job fail when the `check` recipe attempts to run `cargo check` on `gix-index`, with the message error: There are multiple `gix-index` packages in your project, and the specification `gix-index` is ambiguous. Please re-run this command with one of the following specifications: [email protected] [email protected] error: Recipe `check` failed on line 87 with exit code 101 where the line number is from the `justfile`. To fix this, this changes the command to change to the `gix-index` directory instead of passing `-p gix-index`. (This technique is used elsewhere in the same recipe already.)

The previous commit added `gix-testtools` (by relative path) as a dev dependency of `gix-index`, to use `gix_testtools::size_ok`. Because `gix-testtools` itself depends on `gix-index` -- at an earlier version to not break releasing with csr (see discussion in GitoxideLabs#1510 for general info) -- this causes `cargo`, when running in the top level workspace directory, to consider `-p gix-index` without an explicit version to be ambiguous. This made the full CI `test` job fail when the `check` recipe attempts to run `cargo check` on `gix-index`, with the message error: There are multiple `gix-index` packages in your project, and the specification `gix-index` is ambiguous. Please re-run this command with one of the following specifications: [email protected] [email protected] error: Recipe `check` failed on line 87 with exit code 101 where the line number is from the `justfile`. To fix this, this changes the command to change to the `gix-index` directory instead of passing `-p gix-index`. (This technique is used elsewhere in the same recipe already.)

Byron · 2024-12-21T18:17:19Z

As this PR is blocked by technicalities and won't budge for that reason, I am closing it as the issue is likely to persist until cargo smart-release has been adapted to handle this kind of cyclic dependency correctly.

To re-state the problem:

gix-* crates use gix-testtools = { path = "…" } as [dev-dependency].
if gix-testtools also uses gix-* = { path = "…", version = "…" } declarations then the operation.
- The problem probably isn't cargo publish, but cargo smart-release which incorrectly edits the manifests when adjusting crate versions.

The workaround for the problem as it's employed now is to let gix-testtools refer to gix-* crates which have been published before, and are at least a major version in the past. For some reason, it also doesn't work when it refers to crates.io releases of gix crates that are compatible with the respective workspace crates.

Now that I am thinking about it, another solution would be to completely remove all gix-* dependencies from gix-testtools. But after evaluating this option, I had to conclude that it's not possible as it relies on the signal-aware gix-tempfile implementation to assure its tempfiles are always removed.

In theory, gix-tempfile and gix-lock are stable, but in practice they have to get republished due to shortcomings in cargo smart-release - it currently simply can't keep major versions stable, an issue that will need to be fixed before stabilising additional crates.

Thus it's probably better to wait until cargo smart-release gets some additional development time.

The `gix-testtools` crate depends on previous major/breaking versions of some `gix-*` crates, as described in GitoxideLabs#1510 (comment) and further discussed in GitoxideLabs#1886. This creates a situation where `gix-testtools` will sometimes use `gix-*` crates in vulnerable versions. Even as `gix-testtools` is used in this project, that could in principle cause a problem for some vulnerabilities. So it is correct in general to consider vulnerable `gix-testtools` dependencies significant. However, in most vulnerabilities so far, the specific use in `gix-testtools` as part of gitoxide's test suite has been acceptable. (Other common uses of `gix-testtools`, if they are in test suites operating on trusted data as here, may be in a similar situation, but it may not be reasonable to assume that broadly.) When `cargo deny advisories` fails on CI due to a `gix-testtools` dependency on an old version of a `gix-*` crate, it makes it harder to notice if *other* vulnerable dependencies are also being used. A usual workaround for this would be to add the vulnerability's RUSTSEC ID to the `ignore` list in `deny.toml`, but that would weaken the operation of `cargo deny` far too much, because: - The distraction here is mainly, or perhaps only, a problem in CI, so no change to `deny.toml` may be needed. - It should remain easy to run `cargo deny` in such a way that the dependence of `gix-testtools` on vulnerable crate versions is revealed, and it should be obvious from the command that is run whether that information would be shown or not. - The advisories themselves should not be ignored because they are unexpected, and potentially highly consequently, if they arise from any other crate. - It is useful to be able to easily compare the output of `cargo deny advisories` with and without such messages. So this multiplies the step into two, running `cargo deny` twice for advisories: 1. Initially including dependencies through `gix-testtools`, but marking the step as `continue-on-error: true` so it doesn't fail the job. 2. Again without dependencies through `gix-testtools`, allowing the step to fail the job on vulnerabilities found via other crates.

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.0 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in this workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the benefit here is that ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. In particular, a number of actions we prefer `<cmd> -p <crate>` for were done by `(cd <crate-dir>; <cmd>)`, in the `justfile` and when doing them manually. This included `cargo nextest run` and `cargo check` on some crates. Here's an example (shown on Windows, but the problem was not specific to Windows): C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, such as in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. A further benefit is that the lockfile and dependency tree are simpler. However, that points to an important aspect of this change: it is more than a refactoring. Although it shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. But: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published.

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.0 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in this workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the benefit here is that ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. In particular, a number of actions we prefer `<cmd> -p <crate>` for were done by `(cd <crate-dir>; <cmd>)` to operate on `gix-*` crates in the workspace that are also dependencies of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (directly via `just`, or directly in script steps), some some operations carried out manually. This included `cargo nextest run` and `cargo check` on some crates. Here's an example (shown on Windows, but this was not specific to Windows): C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, such as in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. A further benefit is that the lockfile and dependency tree are simpler. However, that points to an important aspect of this change: it is more than a refactoring. Although it shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. But: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published.

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.0 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in this workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the benefit here is that ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. In particular, a number of actions we prefer `<cmd> -p <crate>` for were done by `(cd <crate-dir>; <cmd>)` to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (directly via `just`, or directly in script steps), some some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, such as in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. A further benefit is that the lockfile and dependency tree are simpler. However, that points to an important aspect of this change: it is more than a refactoring. Although it shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. But: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published.

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.0 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in this workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the benefit here is that ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. In particular, a number of actions we prefer `<cmd> -p <crate>` for were done by `(cd <crate-dir>; <cmd>)` to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (indirectly via `just`, or directly in script steps), some some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, such as in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. A further benefit is that the lockfile and dependency tree are simpler. However, that points to an important aspect of this change: it is more than a refactoring. Although it shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. But: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published.

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.0 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in this workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the benefit here is that ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. In particular, a number of actions we prefer `<cmd> -p <crate>` for were done by `(cd <crate-dir>; <cmd>)` to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (indirectly via `just`, or directly in script steps), and some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, such as in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. A further benefit is that the lockfile and dependency tree are simpler. However, that points to an important aspect of this change: it is more than a refactoring. Although it shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. But: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published.

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.1 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify both `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in the workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the broad benefits here are that: - Ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. - Because the code of the dependency comes from the workspace when applicable, i.e. when `gix-testtools` is itself being used in the workspace, it should allow new not-yet-published functionality to be leveraged in `gix-testtools`, without confusion or breakage. Before this, some actions we'd prefer to do by `<cmd> -p <crate>` had to be done by `(cd <crate-dir>; <cmd>)`. This was needed to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (indirectly via `just`, or directly in script steps), and some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, especially in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. For further details, see GitoxideLabs#1989. Another benefit is that the lockfile and dependency tree are simpler, and the dependency tree is truly unified. However, that points to an important aspect of this change, which is more than a refactoring and will affect test behavior: - It shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. - That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. - This is also desirable in that it allows feature changes and bugfixes in `gix-*` crates to be used immediately in `gix-testtools`, before either those `gix-*` crates or `gix-testtools` are published with the changes (GitoxideLabs#1886). But... - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published. Fixes GitoxideLabs#1886 Fixes GitoxideLabs#1989

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.1 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify both `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in the workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the broad benefits here are that: - Ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. - Because the code of the dependency comes from the workspace when applicable, i.e. when `gix-testtools` is itself being used in the workspace, it should allow new not-yet-published functionality to be leveraged in `gix-testtools`, without confusion or breakage. Before this, some actions we'd prefer to do by `<cmd> -p <crate>` had to be done by `(cd <crate-dir>; <cmd>)`. This was needed to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (indirectly via `just`, or directly in script steps), and some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, especially in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. For further details, see GitoxideLabs#1989. Another benefit is that the lockfile and dependency tree are simpler, and the dependency tree is truly unified. That points to an important aspect of this change, which is more than a refactoring and will affect test behavior: - It shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. - That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. - This is also desirable in that it allows feature changes and bugfixes in `gix-*` crates to be used immediately in `gix-testtools`, before either those `gix-*` crates or `gix-testtools` are published with the changes (GitoxideLabs#1886). But... However: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those problem scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published. Fixes GitoxideLabs#1886 Fixes GitoxideLabs#1989

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.1 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify both `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in the workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the broad benefits here are that: 1. Ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. 2. Because the code of the dependency comes from the workspace when applicable, i.e. when `gix-testtools` is itself being used in the workspace, it should allow new not-yet-published functionality to be leveraged in `gix-testtools`, without confusion or breakage. Before this, some actions we'd prefer to do by `<cmd> -p <crate>` had to be done by `(cd <crate-dir>; <cmd>)`. This was needed to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (indirectly via `just`, or directly in script steps), and some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, especially in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. For further details, see GitoxideLabs#1989. Another benefit is that the lockfile and dependency tree are simpler, and the dependency tree is truly unified. That points to an important aspect of this change, which is more than a refactoring and will affect test behavior: - It shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. - That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. - This is also desirable in that it allows feature changes and bugfixes in `gix-*` crates to be used immediately in `gix-testtools`, before either those `gix-*` crates or `gix-testtools` are published with the changes (GitoxideLabs#1886). But... However: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those problem scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published. Fixes GitoxideLabs#1886 Fixes GitoxideLabs#1989

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.1 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify both `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in the workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the broad benefits here are that: 1. Ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. (GitoxideLabs#1989) 2. Because the code of the dependency comes from the workspace when applicable, i.e. when `gix-testtools` is itself being used in the workspace, it should allow new not-yet-published functionality to be leveraged in `gix-testtools`, without confusion or breakage. (GitoxideLabs#1886) Before this, some actions we'd prefer to do by `<cmd> -p <crate>` had to be done by `(cd <crate-dir>; <cmd>)`. This was needed to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (indirectly via `just`, or directly in script steps), and some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, especially in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. For further details, see GitoxideLabs#1989. Another benefit is that the lockfile and dependency tree are simpler, and the dependency tree is truly unified. That points to an important aspect of this change, which is more than a refactoring and will affect test behavior: - It shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. - That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. - This is also desirable in that it allows feature changes and bugfixes in `gix-*` crates to be used immediately in `gix-testtools`, before either those `gix-*` crates or `gix-testtools` are published with the changes (GitoxideLabs#1886). But... However: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those problem scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published. Fixes GitoxideLabs#1886 Fixes GitoxideLabs#1989

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.1 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify both `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in the workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testtools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the broad benefits here are that: 1. Ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. (GitoxideLabs#1989) 2. Because the code of the dependency comes from the workspace when applicable, i.e. when `gix-testtools` is itself being used in the workspace, it should allow new not-yet-published functionality to be leveraged in `gix-testtools`, without confusion or breakage. (GitoxideLabs#1886) Before this, some actions we'd prefer to do by `<cmd> -p <crate>` had to be done by `(cd <crate-dir>; <cmd>)`. This was needed to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (indirectly via `just`, or directly in script steps), and some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, especially in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. For further details, see GitoxideLabs#1989. Another benefit is that the lockfile and dependency tree are simpler, and the dependency tree is truly unified. That points to an important aspect of this change, which is more than a refactoring and will affect test behavior: - It shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. - That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. - This is also desirable in that it allows feature changes and bugfixes in `gix-*` crates to be used immediately in `gix-testtools`, before either those `gix-*` crates or `gix-testtools` are published with the changes (GitoxideLabs#1886). But... However: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those problem scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published. Fixes GitoxideLabs#1886 Fixes GitoxideLabs#1989

`gix-testtools` depends on several other `gix-*` crates. Before version 0.16.1 (GitoxideLabs#1972), `gix-testtools` depended on prior breaking versions of those crates (as discussed in GitoxideLabs#1510 and GitoxideLabs#1886). Since then, it depends on the current versions. When depending on a strictly earlier version, it was necessary to omit `path =` in the `gix-testtools` manifest for its `gix-*` dependencies. Now that `gix-testtools` depends on current versions of those dependencies, it seems feasible to specify both `version` and `path`, as we do in other cases where one crate developed in this workspace depends on another crate developed in the workspace. Aside from improving general consistency (which is a weak rationale here, since the role of `gix-testtools` differs substantially from that of other `gix-*` crates, in terms of how we're ourselves using it), the broad benefits here are that: 1. Ambiguity in what crate is meant, when an operation is performed on a specific `gix-*` crate, is lessened, or maybe even eliminated. (GitoxideLabs#1989) 2. Because the code of the dependency comes from the workspace when applicable, i.e. when `gix-testtools` is itself being used in the workspace, it should allow new not-yet-published functionality to be leveraged in `gix-testtools`, without confusion or breakage. (GitoxideLabs#1886) Before this, some actions we'd prefer to do by `<cmd> -p <crate>` had to be done by `(cd <crate-dir>; <cmd>)`. This was needed to operate on `gix-*` crates in the workspace that are also dependencies, even transitively, of `gix-testtools`. This affected some commands in `justfile` recipes, some commands run in CI workflows (indirectly via `just`, or directly in script steps), and some operations carried out manually. This included `cargo nextest run` and `cargo check` on various crates. Here's an example (shown on Windows, but this problem was not specific to Windows) using `gix-date`, which is not listed in `tests/tools/Cargo.toml`, but which is a transitive dependency: C:\Users\ek\source\repos\gitoxide [main ≡]> cargo nextest run -p gix-date Blocking waiting for file lock on package cache error: There are multiple `gix-date` packages in your project, and the specification `gix-date` is ambiguous. Please re-run this command with one of the following specifications: path+file:///C:/Users/ek/source/repos/gitoxide/gix-date#0.10.1 registry+https://github.com/rust-lang/crates.io-index#[email protected] error: command `'\\?\C:\Users\ek\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\cargo.exe' test --no-run --message-format json-render-diagnostics --package gix-date` exited with code 101 An important special case is that of editor/IDE integration, especially in VS Code. This couldn't run and (more significantly, in view of the benefit of integration) couldn't debug some of the tests. This happened because synthesized `cargo test -p ...` commands, used behind the scenes to launch the tests, were ambiguous. For further details, see GitoxideLabs#1989. Another benefit is that the lockfile and dependency tree are simpler, and the dependency tree is truly unified. That points to an important aspect of this change, which is more than a refactoring and will affect test behavior: - It shouldn't produce different behavior when `gix-testtools` is obtained from crates.io (i.e. when projects developed outside the `gitoxide` repository use `gix-testtools`), it can produce different behavior here, where `gix-testtools` will use changes to its `gix-*` dependencies (and accordingly their own dependencies, recursively) that are present in the workspace even if not present in the released version that matches `version =`. - That could be a good thing if it causes new changes to be exercised more and earlier. That might help find bugs. - This is also desirable in that it allows feature changes and bugfixes in `gix-*` crates to be used immediately in `gix-testtools`, before either those `gix-*` crates or `gix-testtools` are published with the changes (GitoxideLabs#1886). But... However: - It could be bad if it introduces an undesirable dependency ordering for fixing bugs and/or introducing regression tests. That is, in principle there could arise two (possibly related) bugs, A and B, where there is some reason to fix A before B, but where B must be fixed in order for the regression test for A to run (to validate that it can catch A), due to B breaking `gix-testtools` as used in the test for A or in other tests in the crate affected by A. Because this would presumably be known--an error would occur, likely when building the tests--it could be worked around by temporarily (or permanently) reverting this change if and when such a problem ever arises, or partially undoing it for the specific affected `gix-*` dependency of `gix-testtools`. - It could be bad if a bug affects a `gix-*` crate and its own tests in identical or complementary ways, and this is used to establish or check an expectation. That is, in principle there could arise a bug in a `gix-*` crate that `gix-testtools` uses, and that itself uses `gix-testtools` in its tests, that causes a test that should catch that bug (either initially or to verify a bugfix) to wrongly report that the code is working. This scenario is a case of the general problem that duplicated logic between code and its tests can cause a bug to appear (either in the same form or in different forms) in both, such that tests that should catch the bug don't catch it because they suffer from the same bug. In the hypothetical case imagined here, the duplication of logic would arise from the tests calling and using the very code that is under test. For the way we are currently using or likely ever to use `gix-testtools`, it seems like this would probably not happen. But it is hard to be completely sure. Unlike the previously described scenario, if this scenario did occur, it would likely not be noticed. Both those problem scenarios have corresponding scenarios that had already applied (and which the change here at least slightly *mitigates*): if the code with the bug has already been published. This fixes GitoxideLabs#1989 and makes progress toward GitoxideLabs#1886.

gix-testtools: Upgrade versions of gix crates

057db6e

This avoids duplicate dependencies in packages depending on both gix and gix-testtools.

EliahKagan mentioned this pull request Aug 22, 2024

fixes #1536

Merged

Byron closed this Dec 21, 2024

EliahKagan mentioned this pull request Jan 26, 2025

Rename Exponential backoff to Quadratic #1815

Merged

EliahKagan mentioned this pull request Mar 14, 2025

Using the latest shell() or related facility in bash_program() #1886

Open

EliahKagan mentioned this pull request Apr 5, 2025

build(deps): bump openssl from 0.10.71 to 0.10.72 in the cargo group across 1 directory #1924

Merged

This was referenced Apr 17, 2025

Vulnerable gix-features is not only a dev dependency GitoxideLabs/cargo-smart-release#50

Closed

Enable Dependabot version updates for Rust GitoxideLabs/cargo-smart-release#52

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gix-testtools: Upgrade versions of gix crates #1510

gix-testtools: Upgrade versions of gix crates #1510

joshtriplett commented Aug 11, 2024

joshtriplett commented Aug 11, 2024 •

edited

Loading

Byron commented Aug 12, 2024 •

edited

Loading

Byron commented Dec 21, 2024

gix-testtools: Upgrade versions of gix crates #1510

gix-testtools: Upgrade versions of gix crates #1510

Conversation

joshtriplett commented Aug 11, 2024

joshtriplett commented Aug 11, 2024 • edited Loading

Byron commented Aug 12, 2024 • edited Loading

Byron commented Dec 21, 2024

joshtriplett commented Aug 11, 2024 •

edited

Loading

Byron commented Aug 12, 2024 •

edited

Loading