prepare new testtools release #1972

Byron · 2025-04-27T08:03:43Z

With this release downstream will finally have a fix for audit-failures,
as it now uses a fixed version of gix-features.

…ding to `gix-features 0.42` This is what should silence audit failures.

Byron · 2025-04-27T08:29:33Z

@EliahKagan This PR also updates the gix-testtools dependencies to the very latest version. This is supposed to create an incentive to fix CSR on the next regular gitoxide release, or alternatively, temporarily downgrade the gix-testtools dependencies.
The idea is that in the worst case, one will release gix-testtools with gix so there is no duplication, and then downgrade the dependencies locally afterwards so the next gitoxide release can go through unimpeded.
I somehow think that CSR should be able to deal with the case where gix-testtools refers to the latest published version of these crates, and if not it should be very possible to teach it.

`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#gix-date@0.10.1 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#gix-date@0.10.1 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#gix-date@0.10.1 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#gix-date@0.10.1 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#gix-date@0.10.1 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#gix-date@0.10.1 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#gix-date@0.10.1 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#gix-date@0.10.1 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#gix-date@0.10.1 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#gix-date@0.10.1 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

…tools" This reverts commit 67d9bf4, but not the other changes from GitoxideLabs#1927. `gix-testtools` 0.16.1 has the change in 9b12d50 (GitoxideLabs#1972) from depending on previous SemVer-incompatible versions of `gix-*` crates to depending on the current versions. Since then, nothing affected by https://rustsec.org/advisories/RUSTSEC-2024-0436.html appears in our dependency tree, and it is no longer necessary or desirable to use a more complicated `cargo deny check advisories` scanning approach allowing that advisory through `gix-testtools`.

`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#gix-date@0.10.1 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#gix-date@0.10.1 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.

prepare new testtools release

070f5f6

Byron force-pushed the gix-testtools branch from 45bda80 to 070f5f6 Compare April 27, 2025 08:05

Release gix-testtools v0.16.0

c5c726e

Byron marked this pull request as ready for review April 27, 2025 08:13

Byron enabled auto-merge April 27, 2025 08:13

Byron disabled auto-merge April 27, 2025 08:16

fix: unify the dependency graph by choosing the right versions, upgra…

9b12d50

…ding to `gix-features 0.42` This is what should silence audit failures.

Release gix-testtools v0.16.1

48079a5

Byron enabled auto-merge April 27, 2025 08:35

Byron merged commit d2f2333 into main Apr 27, 2025
24 checks passed

Byron deleted the gix-testtools branch April 27, 2025 09:39

EliahKagan mentioned this pull request May 4, 2025

Can't run/debug tests in VS Code for crates gix-testtools depends on #1989

Closed

EliahKagan mentioned this pull request May 5, 2025

Stop special-casing RUSTSEC-2025-0021 for cargo deny on CI #1991

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

prepare new testtools release #1972

prepare new testtools release #1972

Byron commented Apr 27, 2025

Byron commented Apr 27, 2025

prepare new testtools release #1972

prepare new testtools release #1972

Conversation

Byron commented Apr 27, 2025

Byron commented Apr 27, 2025