kinnison / git-testament

Rust library for creating a commit testament at compile time
BSD 3-Clause "New" or "Revised" License
47 stars 10 forks source link

Please include the test-template folder in crates.io uploads #24

Closed werdahias closed 1 year ago

werdahias commented 1 year ago

The test-template folder which is needed for running the tests isn't included in the crates.io upload of git-testament. Please consider including it.

kinnison commented 1 year ago

I have tried to, usually, stick to "external data needed for tests is only relevant for people developing the crate" however in this instance I think the data is small enough that it's fine to include in the .crate upload. I shall do this for the next point release.

May I ask what your use-case is for this? Are you packaging for a distro?

werdahias commented 1 year ago

I maintain your crate for debian and it would be beneficial if the testdata was included so the test could run.

kinnison commented 1 year ago

I maintain your crate for debian and it would be beneficial if the testdata was included so the test could run.

That's certainly a good reason; I shall endeavour to make a release very soon.

Out of interest, which crates in Debian depend on git-testament? It seems a little sad that they won't be getting a testament inserted given debian packages don't build from git checkouts :(

werdahias commented 1 year ago

Well the whole debian rust packagaging is built around crates.io releases (currently). there has been some discussion around that but I think it will stay as-is. I maintain git-testament (derive) as dependency for rustup.

kinnison commented 1 year ago

I maintain git-testament (derive) as dependency for rustup.

Oh interesting, how is Debian packaging rustup? Surely doing it properly would result in conflicting with the rustc and cargo packages etc?

werdahias commented 1 year ago

rustup is not yet in debian, though I am working on it. The debian rustc/cargo is placed in /usr/bin afaik and rustup would go into .cargo or something.

kinnison commented 1 year ago

If you're packaging rustup-init then that's very different and I'd admonish you not to do that if you can avoid it. If you're going to package rustup then there's a bunch of proxies you should set up which would include rustc cargo etc. rather than expecting each user to have a $CARGO_HOME/bin/.... Unfortunately to do that properly would mean you'd conflict with the rustc cargo etc. packages which already exist. It's a rough situation to work through; but I trust that you'll find the best route.

If you want to discuss further, I am part of the rustup team upstream; and also I used to package rustup for snap (though we stopped doing that because snapcraft was too unreliable in our CI) and I'm aware of how distros like nixos deal with it.

werdahias commented 1 year ago

Thanks for the input. The rust team and me are definitly working on rustup. Once git-testament and xz2 are in unstable I can work on it. Apt has mechanics to detect collisions between packages if that would happen, but afaik you can install it in paralllel. What would help us if the download crate for rustup was published on crates.io (and maybe rustup itself?).

kinnison commented 1 year ago

I believe 0.2.4 (now out) should contain the files. It also obeys CARGO_TARGET_TMPDIR

werdahias commented 1 year ago

thanks :)