add version information to dev-dependencies of gix-command

[alexanderkjall]

The published crate is missing the dev-dependencies: https://docs.rs/crate/gix-command/0.2.10/source/Cargo.toml

Which makes it harder to run the unittests for the crate when we package it for Debian.

This is the change that removes the dependencies: rust-lang/cargo#7333

[Byron]

Thanks for the fix, but I wonder if that's all that will be needed as none of the dev-dependencies have their version specified.

Further, all crates are packaged specifically not to contain necessary fixtures to run tests as I consider crates to be for download and use only. Integration tests are stripped as well.

In order to be able to publish these crates, no dev-dependency that is also a workspace crate may have its version specified.

Maybe I am missing something, but to me it looks like there is much more to be done to make tests work with packages from crates.io.

[alexanderkjall]

Yes, I agree with your analysis that more needs to be done if we look at all the gix crates.

I typically work in the context of a single crate when doing the packaging, as one crate typically equal one Debian package.

I prefer being able to run your tests for the packages, as that helps ensuring that no accidental breakage of the software occurs, but if you have strong opinions on them being for download use only, then I might need to reconsider.

[Byron]

I prefer being able to run your tests for the packages, as that helps ensuring that no accidental breakage of the software occurs, but if you have strong opinions on them being for download use only, then I might need to reconsider.

I think it's fair to optimize a published crate for the common case, which is the usage of the crate within a dependency tree, which means to minimize the download size. From that point of view, I should probably also not include changelogs, as they only grow larger.

However, other uses should also be supported, but for that I currently only see the source repository or source tarballs as they are downloaded from GitHub. For maximum trust, I think there is no way around a clone of the repository though.

Each release of each crate is tagged (i.e. git tag | rg gix-command), so it should be possible to package each crate from their original sources. Something I'd be doing is to run the tests from the repository clone, and then package a crate myself with cargo package to be sure the tested code and the package match.

If anything would be missing when trying that, I'd be happy to help making it work. If there is anything I am missing or should consider, please let me know as well (as long as downloads from crates.io remain as small as possible). Thank you.

[alexanderkjall]

Our packaging tooling is fairly automated, and uses the published artifacts on crates.io. As that is the code that is published and used everywhere else, including the security advisories from rustsec, trying to automate pulling in testdata from github while ensuring that nothing else gets messed up feels like a rabbit hole that I'm not very keen on exploring :)

Seems like I just have to maintain this patch on the Debian side :)